From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23520 invoked by alias); 18 Jun 2003 18:41:07 -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 23432 invoked from network); 18 Jun 2003 18:41:05 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 18 Jun 2003 18:41:05 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h5IIf4H19961 for ; Wed, 18 Jun 2003 14:41:04 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5IIf2S25890; Wed, 18 Jun 2003 14:41:03 -0400 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h5IIf2K13743; Wed, 18 Jun 2003 11:41:02 -0700 Message-ID: <3EF0B23E.8040406@redhat.com> Date: Wed, 18 Jun 2003 18:41:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner CC: Kris Warkentin , Daniel Jacobowitz , "Gdb@Sources.Redhat.Com" Subject: Re: Why does solib_open do what it does? References: <09c201c33502$da555ce0$0202040a@catdog> <20030617191129.GA15099@nevyn.them.org> <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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00389.txt.bz2 Kevin Buettner wrote: > On Jun 17, 9:54pm, Kris Warkentin wrote: > > >>>>Michael, any comments? >>> >>>I don't remember. ;-( >>>I'll just remark that ld puts full paths in for some libs, and not for >> >>others. >> >>>That's why there are two variables, SOLIB-SEARCH-PATH and >>>SOLIB-ABSOLUTE-PREFIX. One is the prefix that goes before everything >>>(even rooted filespecs), and the other is the additional prefix that >>>goes before an un-rooted filespec. >> >>Okay then, here's what I propose. >> >>1) Change the order as Kevin suggested earlier. This give the user plenty >>of opportunity to tell gdb how to find the solibs before we thrash about >>desperately in LD_LIBRARY_PATH, etc. > > > Definitely okay. > > >>2) Take out the solib_search_path check in the if(found_file <0 && >>solib_search_path != NULL) parts of the last two desperation plays. I don't >>think there's any reason for them. > > > Wow. Good catch. I don't understand them either. But... > > >>I have a feeling that we want to leave the last two searches in place simply >>because native debugging is the most common and they probably catch a lot of >>action. Most people doing remote debugging are setting up their >>solib-absolute-prefix and such properly anyway. > > > Given the fact that these tests are here, I don't think that the $PATH > and $LD_LIBRARY_PATH checks are ever actually used for native > debugging. > > After all, who bothers to set solib_search_path when doing native > debugging? And if you do set solib_search_path, doesn't it seem > strange that these additional checks suddenly become enabled? > > So, at this point we have two choices: a) Do away with the $PATH and > $LD_LIBRARY_PATH code altogether, or b) Do as you suggest and remove > the ``solib_search_path != NULL'' check. > > If we can actually convince ourselves that leaving in the $PATH and > $LD_LIBRARY_PATH checks serve a useful purpose, option b is the way to > go. At the moment, however, I'm strongly leaning towards option a. You don't think that gdb should honor LD_LIBRARY_PATH in native debugging, if it is set? Won't the linker-loader honor it? I'd be ready to agree that, if solib-search-path is set, it should override LD_LIBRARY_PATH. But if it isn't set... > In fact, for remote debugging, leaving these checks in is rather > dangerous. If, for some reason, the shared lib is not found via > either solib-absolute-prefix or solib-search-path, we don't want > to search paths on the host file system which refer to the hosts > libraries. If the file is found via one of these paths, it is > almost certainly wrong, and I've seen cases where this can cause > wildly unpredictable behavior. (E.g, segfaults on the target, or > breakpoints being hit at strange places.) Agreed. Indeed, I think LD_LIBRARY_PATH is required for native, and always wrong for cross. Is there any way we can use that distinction? Maybe with a configure variable? > I think I could be convinced to leave these checks in if we > were to replace that ``solib_search_path != NULL'' conjunct with > ``solib_absolute_prefix == NULL'' instead. That is, if you set > solib_absolute_prefix, then $PATH and $LD_LIBRARY_PATH will never > be considered. (I guess there were actually three choices. We'll > call this one option c.) > > Opinions? How about (d) a configure variable that enables the tests for native only.