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:12:00 -0000 Message-id: <20011127101232.A25024@nevyn.them.org> References: <3BEAA3A0.586B3046@axis.com> <20011108110955.A12240@nevyn.them.org> <3C03AB51.DB27B3D4@axis.com> X-SW-Source: 2001-11/msg00493.html On Tue, Nov 27, 2001 at 04:03:45PM +0100, Orjan Friberg wrote: > Daniel Jacobowitz wrote: > > > > Other than that, we should fall back to solib-search-path and the > > basename if solib-absolute-path fails for us, IMO. Would that work for > > you? Set the absolute-path to /dev/null or so and then add the > > fallback code. > > A quick recap: I'm doing solib debugging in a cross-environment, but the path to the > target's solibs on my host doesn't correspond to the path on the target. More > specifically, the path where I want to get the solibs from on my host doesn't end in > /lib. > > This is a first shot at it. The latter part of the patch implements what Daniel > suggested, but the first part is more controversial. The problem is when in_pathname > contains an absolute path (say /lib/libc.so.6), but it's not found in the path > specified by solib_absolute_prefix. When we try and search for the solib in > solib_search_path, openp will find that the file name is an absolute path and open it > (ignoring the supplied solib_search_path). As a result, it will pick up > /lib/libc.so.6 on my host. > > 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. Perhaps you need to propogate knowledge of whether we are debugging natively down to this point? -- 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 23607 invoked by alias); 27 Nov 2001 15:12:20 -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 23571 invoked from network); 27 Nov 2001 15:12:19 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 15:12:19 -0000 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 168juS-0007pV-00; Tue, 27 Nov 2001 10:12:32 -0500 Date: Wed, 14 Nov 2001 12:59: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: <20011127101232.A25024@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C03AB51.DB27B3D4@axis.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-11/txt/msg00278.txt.bz2 Message-ID: <20011114125900.IO4jCdwTbMSIZH6y0JeoVZ30O6rlXQ3QuuDGQ2pzWwk@z> On Tue, Nov 27, 2001 at 04:03:45PM +0100, Orjan Friberg wrote: > Daniel Jacobowitz wrote: > > > > Other than that, we should fall back to solib-search-path and the > > basename if solib-absolute-path fails for us, IMO. Would that work for > > you? Set the absolute-path to /dev/null or so and then add the > > fallback code. > > A quick recap: I'm doing solib debugging in a cross-environment, but the path to the > target's solibs on my host doesn't correspond to the path on the target. More > specifically, the path where I want to get the solibs from on my host doesn't end in > /lib. > > This is a first shot at it. The latter part of the patch implements what Daniel > suggested, but the first part is more controversial. The problem is when in_pathname > contains an absolute path (say /lib/libc.so.6), but it's not found in the path > specified by solib_absolute_prefix. When we try and search for the solib in > solib_search_path, openp will find that the file name is an absolute path and open it > (ignoring the supplied solib_search_path). As a result, it will pick up > /lib/libc.so.6 on my host. > > 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. Perhaps you need to propogate knowledge of whether we are debugging natively down to this point? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer