From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16679 invoked by alias); 19 Jun 2003 23:33:30 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8776 invoked from network); 19 Jun 2003 23:16:23 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 19 Jun 2003 23:16:23 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h5JNGNH23201 for ; Thu, 19 Jun 2003 19:16:23 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5JNGMI01824; Thu, 19 Jun 2003 19:16:22 -0400 Received: from localhost.localdomain (vpn50-21.rdu.redhat.com [172.16.50.21]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5JNGLd06963; Thu, 19 Jun 2003 19:16:21 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h5JNGF204726; Thu, 19 Jun 2003 16:16:15 -0700 Date: Thu, 19 Jun 2003 23:33:00 -0000 From: Kevin Buettner Message-Id: <1030619231615.ZM4725@localhost.localdomain> In-Reply-To: "Kris Warkentin" "Re: Why does solib_open do what it does?" (Jun 19, 8:24am) References: <09e801c33504$bd88b420$0202040a@catdog> <1030617200144.ZM31327@localhost.localdomain> <0ab001c3350d$359af2e0$0202040a@catdog> <1030617202406.ZM31423@localhost.localdomain> <3EEFAEDB.4090509@redhat.com> <005101c3353c$80077c70$2a00a8c0@dash> <1030618051511.ZM11645@localhost.localdomain> <3EF0B23E.8040406@redhat.com> <20030618191600.GB9449@nevyn.them.org> <3EF0C77A.5000007@redhat.com> <20030618202726.GA11078@nevyn.them.org> <3EF0D0AD.6000204@redhat.com> <046901c3365d$c68e2a50$0202040a@catdog> To: "Kris Warkentin" Subject: Re: Why does solib_open do what it does? Cc: "Michael Snyder" , "Daniel Jacobowitz" , "Gdb@Sources.Redhat.Com" , "Kevin Buettner" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00407.txt.bz2 On Jun 19, 8:24am, Kris Warkentin wrote: > > > In Linux it's the case for all searched-for objects, as far as I know - > > > anything found via search paths, LD_LIBRARY_PATH, DT_RUNPATH, DT_RPATH, > > > etc. will either be an absolute path or else contain slashes and be > > > relative to the current directory. If it's not true for dlopen'd > > > objects, well, there's no way to know where the app had chdir'd to when > > > it loaded them. > > > > > > Do you know offhand when it's not true for GNU/Linux? > > > > No, I just recall that, several years ago when I worked on this code, > > it was not always true. > > Okay gentlemen, all kidding aside, what do we do? At the bare minimum I > believe the test > > /* If not found, next search the inferior's $PATH environment variable. */ > if (found_file < 0 && solib_search_path != NULL) > > should be just: > > if (found_file < 0). > > We can always make a decision about removing the PATH and LD_LIBRARY_PATH > checks later. Okay, I've come to a decision. It's still not clear to me if the PATH and LD_LIBRARY_PATH searches are needed for natives. Either they're not needed or nobody's noticed that some previously available functionality (prior to Nov 21, 2000) is now missing. I do know, however, that we definitely don't want to do these searches for (most) remote targets. In light of Michael's remarks, I'm now inclined to be more cautious about removing these searches than I was originally. Further, if you're debugging a remote target, you'd better have solib-absolute-prefix set, or things will almost certainly go wrong. To the best of my knowledge, when you're debugging a native target, you never set solib-absolute-prefix, so the fact that this is set or not gives us a cheap, but effective way to determine whether the intent is to run on a native target or not. Actually, it's better than that. Something that I occassionally do is to run against a "native" rda or gdb server where I don't set solib-absolute-prefix. Doing things in this fashion will make search algorithm for this kind of "remote" (which is really a native disguised as a remote) target identical to running a native and that is precisely what's desired. So... I'd like to see the checks preceding the PATH and LD_LIBRARY_PATH searches changed from: if (found_file < 0 && solib_search_path != NULL) to: if (found_file < 0 && solib_absolute_prefix == NULL) Kris, I believe you volunteered to make the necessary changes. Would you like to do the honors? BTW, your proposed comment changes look good too. Consider these changes preapproved, but do make sure you post the patch that you end up committing. Thanks, Kevin