From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4450 invoked by alias); 28 Nov 2001 09:03:04 -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 4414 invoked from network); 28 Nov 2001 09:03:02 -0000 Received: from unknown (HELO krynn.axis.se) (193.13.178.10) by hostedprojects.ges.redhat.com with SMTP; 28 Nov 2001 09:03:02 -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 fAS92vCJ028324; Wed, 28 Nov 2001 10:02:57 +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 KAA17473; Wed, 28 Nov 2001 10:02:57 +0100 X-Authentication-Warning: ironmaiden.axis.se: Host localhost [127.0.0.1] claimed to be axis.com Message-ID: <3C04A841.B3414DA@axis.com> Date: Fri, 16 Nov 2001 13:47: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> <3C03B2E8.8409512@axis.com> <20011127104345.A1939@nevyn.them.org> <3C03DAB3.8240E639@axis.com> <20011127134600.A11327@nevyn.them.org> <3C03E660.B33DF385@axis.com> <20011127142935.A12983@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00317.txt.bz2 Daniel Jacobowitz wrote: > > On Tue, Nov 27, 2001 at 08:15:44PM +0100, Orjan Friberg wrote: > > Daniel Jacobowitz wrote: > > > > > > Suppose that I dlopen ("/lib/mmx/libc.so.6", ...). That's the case I > > > am describing. The only way to handle this case properly (assuming > > > there is also a /lib/libc.so.6) is to go through one of the absolute > > > path cases. There is no other option. > > > > But won't dlopen ("/lib/mmx/libc.so.6", ...) be handled by: > > > > if (! IS_ABSOLUTE_PATH (in_pathname) || solib_absolute_prefix == NULL) > > temp_pathname = in_pathname; > > else > > { > > [Catting of prefix and pathname] > > } > > > > /* Now see if we can open it. */ > > found_file = open (temp_pathname, O_RDONLY, 0); > > > > That counts as an absolute path case, right? > > > > I can't see why we'd rely on the first openp to handle dlopen ("/lib/mmx/libc.so.6", > > ...) since it's an absolute path and should be handled by the code above. That's why > > I suggest we know we should look in solib_search_path (and thus should get rid of the > > leading '/' which makes it an absolute path). > > Oh! I was confused; sorry. No problem; thanks for taking the time to review my patch. > I think your patch is OK. If we fail to find it in the absolute path, > search for its "absolute" (without leading directory separator[s]) > path in each directory in the solib-search-path. Then try searching > for its basename as a last resort. Right? Right. (And if basename search fails, we search $PATH and $LD_LIBRARY_PATH like before.) I will post an updated patch shortly. -- 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: Wed, 28 Nov 2001 01:03:00 -0000 Message-ID: <3C04A841.B3414DA@axis.com> References: <3BEAA3A0.586B3046@axis.com> <20011108110955.A12240@nevyn.them.org> <3C03AB51.DB27B3D4@axis.com> <20011127101232.A25024@nevyn.them.org> <3C03B2E8.8409512@axis.com> <20011127104345.A1939@nevyn.them.org> <3C03DAB3.8240E639@axis.com> <20011127134600.A11327@nevyn.them.org> <3C03E660.B33DF385@axis.com> <20011127142935.A12983@nevyn.them.org> X-SW-Source: 2001-11/msg00532.html Message-ID: <20011128010300.VgKAlzVAvNBs4CYoUQBkl09UsQLrqxnpydfBZeBE7Hw@z> Daniel Jacobowitz wrote: > > On Tue, Nov 27, 2001 at 08:15:44PM +0100, Orjan Friberg wrote: > > Daniel Jacobowitz wrote: > > > > > > Suppose that I dlopen ("/lib/mmx/libc.so.6", ...). That's the case I > > > am describing. The only way to handle this case properly (assuming > > > there is also a /lib/libc.so.6) is to go through one of the absolute > > > path cases. There is no other option. > > > > But won't dlopen ("/lib/mmx/libc.so.6", ...) be handled by: > > > > if (! IS_ABSOLUTE_PATH (in_pathname) || solib_absolute_prefix == NULL) > > temp_pathname = in_pathname; > > else > > { > > [Catting of prefix and pathname] > > } > > > > /* Now see if we can open it. */ > > found_file = open (temp_pathname, O_RDONLY, 0); > > > > That counts as an absolute path case, right? > > > > I can't see why we'd rely on the first openp to handle dlopen ("/lib/mmx/libc.so.6", > > ...) since it's an absolute path and should be handled by the code above. That's why > > I suggest we know we should look in solib_search_path (and thus should get rid of the > > leading '/' which makes it an absolute path). > > Oh! I was confused; sorry. No problem; thanks for taking the time to review my patch. > I think your patch is OK. If we fail to find it in the absolute path, > search for its "absolute" (without leading directory separator[s]) > path in each directory in the solib-search-path. Then try searching > for its basename as a last resort. Right? Right. (And if basename search fails, we search $PATH and $LD_LIBRARY_PATH like before.) I will post an updated patch shortly. -- Orjan Friberg Axis Communications AB