From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3692 invoked by alias); 18 Jun 2003 05:33:42 -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 32674 invoked from network); 18 Jun 2003 05:15:19 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 18 Jun 2003 05:15:19 -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 h5I5FJH00991 for ; Wed, 18 Jun 2003 01:15:19 -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 h5I5FII22758; Wed, 18 Jun 2003 01:15:18 -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 h5I5FHg21833; Wed, 18 Jun 2003 01:15:17 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h5I5FBu11646; Tue, 17 Jun 2003 22:15:11 -0700 Date: Wed, 18 Jun 2003 05:33:00 -0000 From: Kevin Buettner Message-Id: <1030618051511.ZM11645@localhost.localdomain> In-Reply-To: "Kris Warkentin" "Re: Why does solib_open do what it does?" (Jun 17, 9:54pm) 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> To: "Kris Warkentin" , "Michael Snyder" , "Kevin Buettner" Subject: Re: Why does solib_open do what it does? Cc: "Daniel Jacobowitz" , "Gdb@Sources.Redhat.Com" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00371.txt.bz2 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. 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.) 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? Kevin