From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4872 invoked by alias); 27 Nov 2001 15:43:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4834 invoked from network); 27 Nov 2001 15:43:35 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 15:43:35 -0000 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 168kOg-0000YN-00; Tue, 27 Nov 2001 10:43:46 -0500 Date: Wed, 14 Nov 2001 13:53:00 -0000 From: Daniel Jacobowitz To: Orjan Friberg Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC]: Solib search (Was: Re: Cross solib support; continued) Message-ID: <20011127104345.A1939@nevyn.them.org> Mail-Followup-To: Orjan Friberg , gdb-patches@sources.redhat.com References: <3BEAA3A0.586B3046@axis.com> <20011108110955.A12240@nevyn.them.org> <3C03AB51.DB27B3D4@axis.com> <20011127101232.A25024@nevyn.them.org> <3C03B2E8.8409512@axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C03B2E8.8409512@axis.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-11/txt/msg00281.txt.bz2 On Tue, Nov 27, 2001 at 04:36:08PM +0100, Orjan Friberg wrote: > Daniel Jacobowitz wrote: > > > > On Tue, Nov 27, 2001 at 04:03:45PM +0100, Orjan Friberg wrote: > > > > > > My thought was to make the path relative if the search for the absolute path failed, > > > by simply getting rid of the leading '/'. (It won't work with DOS based file > > > systems, as the dir separator could be '\\', but that would be easy to add.) > > > Needless to say, this works for me, but I'm not sure it's The Right Thing to do. > > > (Another approach would be to change openp, but I'm sure there's a good reason for > > > its current behaviour.) > > > > I've got one concern with this. In native debugging, we want to open > > the absolute path BEFORE searching solib-search-path - you might have > > dlopened() a specific optimized version of a library whose base exists > > in /usr/lib, for instance. > > I'm not sure I follow: wouldn't that be covered by solib_absolute_prefix being set to > /usr/lib? I mean, I haven't changed the order between searching in > solib_absolute_prefix and solib_search_path. Or do you mean the case where > solib_absolute_prefix isn't set, and we end up searching for it using > LD_LIBRARY_PATH? Hm, maybe we should only make the path relative if we are about to > search for the solib in solib_search_path, leaving the other cases unaffected. That sounds a little better. If there's a /lib/lib or a /usr/lib/usr/lib it's their own fault. I'm still not convinced, though. Consider if we dlopen "/lib/mmx/libc.so.6". (We never do, the dynamic linker takes care of that for this particular case. But for ATLAS it's another story.) We won't find it in solib-search-path. We won't find it if the path is relative. We will only find it if we hand that entire path to openp. We need to not disturb that. Now consider the same thing in a cross environment. This is why I very strongly advocated mirroring the target filesystem. There is no other way to figure out which, if any, libc.so.6 this is. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: Orjan Friberg Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC]: Solib search (Was: Re: Cross solib support; continued) Date: Tue, 27 Nov 2001 07:43:00 -0000 Message-ID: <20011127104345.A1939@nevyn.them.org> References: <3BEAA3A0.586B3046@axis.com> <20011108110955.A12240@nevyn.them.org> <3C03AB51.DB27B3D4@axis.com> <20011127101232.A25024@nevyn.them.org> <3C03B2E8.8409512@axis.com> X-SW-Source: 2001-11/msg00496.html Message-ID: <20011127074300.5vdmjyvD26upYcdZOF3aLG9RwjKk-UAacgFVNQ3H4kk@z> On Tue, Nov 27, 2001 at 04:36:08PM +0100, Orjan Friberg wrote: > Daniel Jacobowitz wrote: > > > > On Tue, Nov 27, 2001 at 04:03:45PM +0100, Orjan Friberg wrote: > > > > > > My thought was to make the path relative if the search for the absolute path failed, > > > by simply getting rid of the leading '/'. (It won't work with DOS based file > > > systems, as the dir separator could be '\\', but that would be easy to add.) > > > Needless to say, this works for me, but I'm not sure it's The Right Thing to do. > > > (Another approach would be to change openp, but I'm sure there's a good reason for > > > its current behaviour.) > > > > I've got one concern with this. In native debugging, we want to open > > the absolute path BEFORE searching solib-search-path - you might have > > dlopened() a specific optimized version of a library whose base exists > > in /usr/lib, for instance. > > I'm not sure I follow: wouldn't that be covered by solib_absolute_prefix being set to > /usr/lib? I mean, I haven't changed the order between searching in > solib_absolute_prefix and solib_search_path. Or do you mean the case where > solib_absolute_prefix isn't set, and we end up searching for it using > LD_LIBRARY_PATH? Hm, maybe we should only make the path relative if we are about to > search for the solib in solib_search_path, leaving the other cases unaffected. That sounds a little better. If there's a /lib/lib or a /usr/lib/usr/lib it's their own fault. I'm still not convinced, though. Consider if we dlopen "/lib/mmx/libc.so.6". (We never do, the dynamic linker takes care of that for this particular case. But for ATLAS it's another story.) We won't find it in solib-search-path. We won't find it if the path is relative. We will only find it if we hand that entire path to openp. We need to not disturb that. Now consider the same thing in a cross environment. This is why I very strongly advocated mirroring the target filesystem. There is no other way to figure out which, if any, libc.so.6 this is. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer