From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1063 invoked by alias); 27 Nov 2001 15:36:21 -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 1022 invoked from network); 27 Nov 2001 15:36:13 -0000 Received: from unknown (HELO krynn.axis.se) (193.13.178.10) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 15:36:13 -0000 Received: from ironmaiden.axis.se (ironmaiden.axis.se [10.13.8.120]) by krynn.axis.se (8.12.1/8.12.1/Debian -2) with ESMTP id fARFa8CJ028945; Tue, 27 Nov 2001 16:36:08 +0100 Received: from axis.com (localhost [127.0.0.1]) by ironmaiden.axis.se (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA10873; Tue, 27 Nov 2001 16:36:08 +0100 X-Authentication-Warning: ironmaiden.axis.se: Host localhost [127.0.0.1] claimed to be axis.com Message-ID: <3C03B2E8.8409512@axis.com> Date: Wed, 14 Nov 2001 13:21:00 -0000 From: Orjan Friberg Organization: Axis Communications AB X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: [RFC]: Solib search (Was: Re: Cross solib support; continued) References: <3BEAA3A0.586B3046@axis.com> <20011108110955.A12240@nevyn.them.org> <3C03AB51.DB27B3D4@axis.com> <20011127101232.A25024@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00280.txt.bz2 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. -- Orjan Friberg Axis Communications AB From mboxrd@z Thu Jan 1 00:00:00 1970 From: Orjan Friberg To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC]: Solib search (Was: Re: Cross solib support; continued) Date: Tue, 27 Nov 2001 07:36:00 -0000 Message-ID: <3C03B2E8.8409512@axis.com> References: <3BEAA3A0.586B3046@axis.com> <20011108110955.A12240@nevyn.them.org> <3C03AB51.DB27B3D4@axis.com> <20011127101232.A25024@nevyn.them.org> X-SW-Source: 2001-11/msg00495.html Message-ID: <20011127073600.vVaFDSgWud1W0V7n0G0flS0P7WpblZjMomuspq--zOg@z> 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. -- Orjan Friberg Axis Communications AB