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 10:45:00 -0000 Message-id: <20011127134600.A11327@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> <20011127104345.A1939@nevyn.them.org> <3C03DAB3.8240E639@axis.com> X-SW-Source: 2001-11/msg00504.html On Tue, Nov 27, 2001 at 07:25:55PM +0100, Orjan Friberg wrote: > Daniel Jacobowitz wrote: > > > > 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. > > I'm sorry; I still fail to see your point. Let me try and break my > thinking down, and I'd be grateful if you could point out where I'm > wrong. To me it seems the question is whether openp should ever be fed > an absolute path in solib_open. > > Using your example, if it's opened as "/lib/mmx/libc.so.6" it's an > absolute path, so it will be handled by the following code: Right. > It will try and open the absolute path, prefixed by > solib_absolute_prefix if it has been set. Right. > Otherwise, it will try the following: > > /* If not found, next search the solib_search_path (if any). */ > if (found_file < 0 && solib_search_path != NULL) > found_file = openp (solib_search_path, > 1, in_pathname, O_RDONLY, 0, &temp_pathname); Also right, of course. > If /lib/mmx/libc.so.6 was opened with a relative path, then > solib_search_path would have to be set correctly for us to find it, no? > What I fail to see is why we'd want openp to open an absolute path, when > we know we want to look in solib_search_path. We don't know that! 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. > > 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. > > I do see your point; falling back on searching on the basename only will > certainly get me in trouble if there are several solibs with the same > name. I also realized just now that an application's solibs won't be in > the same directory on my host as the ones installed with the compiler, > so I'm definitely in trouble (unless we would allow multiple solib > search paths.) Looks like I have to take the mirrored target filesystem > route after all. (That doesn't affect the absolute path vs openp > question though.) solib-search-path is colon separated; why is this a problem? My point still holds, though. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2691 invoked by alias); 27 Nov 2001 18:45:47 -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 2642 invoked from network); 27 Nov 2001 18:45:44 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 18:45:44 -0000 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 168nF2-00031D-00; Tue, 27 Nov 2001 13:46:00 -0500 Date: Wed, 14 Nov 2001 18:28: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: <20011127134600.A11327@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> <20011127104345.A1939@nevyn.them.org> <3C03DAB3.8240E639@axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C03DAB3.8240E639@axis.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-11/txt/msg00289.txt.bz2 Message-ID: <20011114182800.I0G4IDDtsZKiidPaaSxZs6jXMOzFr4kg68eHj_jnyGk@z> On Tue, Nov 27, 2001 at 07:25:55PM +0100, Orjan Friberg wrote: > Daniel Jacobowitz wrote: > > > > 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. > > I'm sorry; I still fail to see your point. Let me try and break my > thinking down, and I'd be grateful if you could point out where I'm > wrong. To me it seems the question is whether openp should ever be fed > an absolute path in solib_open. > > Using your example, if it's opened as "/lib/mmx/libc.so.6" it's an > absolute path, so it will be handled by the following code: Right. > It will try and open the absolute path, prefixed by > solib_absolute_prefix if it has been set. Right. > Otherwise, it will try the following: > > /* If not found, next search the solib_search_path (if any). */ > if (found_file < 0 && solib_search_path != NULL) > found_file = openp (solib_search_path, > 1, in_pathname, O_RDONLY, 0, &temp_pathname); Also right, of course. > If /lib/mmx/libc.so.6 was opened with a relative path, then > solib_search_path would have to be set correctly for us to find it, no? > What I fail to see is why we'd want openp to open an absolute path, when > we know we want to look in solib_search_path. We don't know that! 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. > > 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. > > I do see your point; falling back on searching on the basename only will > certainly get me in trouble if there are several solibs with the same > name. I also realized just now that an application's solibs won't be in > the same directory on my host as the ones installed with the compiler, > so I'm definitely in trouble (unless we would allow multiple solib > search paths.) Looks like I have to take the mirrored target filesystem > route after all. (That doesn't affect the absolute path vs openp > question though.) solib-search-path is colon separated; why is this a problem? My point still holds, though. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer