From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30051 invoked by alias); 28 Nov 2001 00:00:28 -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 30008 invoked from network); 28 Nov 2001 00:00:21 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by hostedprojects.ges.redhat.com with SMTP; 28 Nov 2001 00:00:21 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA07555; Tue, 27 Nov 2001 16:00:18 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.9.3/8.9.3) id RAA13505; Tue, 27 Nov 2001 17:00:02 -0700 Date: Thu, 15 Nov 2001 09:16:00 -0000 From: Kevin Buettner Message-Id: <1011128000002.ZM13504@ocotillo.lan> In-Reply-To: Daniel Jacobowitz "Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)" (Nov 27, 6:48pm) References: <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> <1011127234428.ZM13447@ocotillo.lan> <20011127184805.A23303@nevyn.them.org> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Daniel Jacobowitz , Kevin Buettner Subject: Re: [RFC]: Solib search (Was: Re: Cross solib support; continued) Cc: Orjan Friberg , gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2001-11/txt/msg00304.txt.bz2 On Nov 27, 6:48pm, Daniel Jacobowitz wrote: > On Tue, Nov 27, 2001 at 04:44:28PM -0700, Kevin Buettner wrote: > > On Nov 27, 2:29pm, Daniel Jacobowitz wrote: > > > > > 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? > > > > I don't like it. In particular, the part I don't like is: > > > > + /* If the search in solib_absolute_prefix failed, and the path name is > > + absolute at this point, make it relative. (openp will try and open the > > + file according to its absolute path otherwise, which is not what we want.) > > + Affects all subsequent searches for this solib. */ > > + if (found_file < 0 && IS_DIR_SEPARATOR (in_pathname[0])) > > + in_pathname++; > > + > > > > I do understand Orjan's reasons for doing this, but it seems rather > > fragile to me. I think that we'd be better off doing one of the > > following: > > > > 1) Change openp()'s behavior so that it (optionally) doesn't > > attempt to open a file (which has an absolute path). I.e, > > force it to only consider the paths that we pass it. > > > > 2) Explicitly prepend solib_absolute_prefix to the path in question > > and pass that to openp(). Or, perhaps openp() doesn't even need > > to be called. Perhaps we can do the job with open(). > > If I understand correctly, that's not what he was trying to accomplish. > He was trying to have openp() search for the "absolute" path after each > member of solib-search-path. Am I wrong? You're right. (I misread part of the patch.) I just looked at the patch again. Now that I look at it some more, I think it's okay so long as Eli's concerns are addressed. Kevin From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Daniel Jacobowitz , Kevin Buettner Cc: Orjan Friberg , gdb-patches@sources.redhat.com Subject: Re: [RFC]: Solib search (Was: Re: Cross solib support; continued) Date: Tue, 27 Nov 2001 16:00:00 -0000 Message-ID: <1011128000002.ZM13504@ocotillo.lan> References: <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> <1011127234428.ZM13447@ocotillo.lan> <20011127184805.A23303@nevyn.them.org> X-SW-Source: 2001-11/msg00519.html Message-ID: <20011127160000.f40mfh0nlM3OIwiC5txu1GxMadeDgSWa0zhwSeHV8HY@z> On Nov 27, 6:48pm, Daniel Jacobowitz wrote: > On Tue, Nov 27, 2001 at 04:44:28PM -0700, Kevin Buettner wrote: > > On Nov 27, 2:29pm, Daniel Jacobowitz wrote: > > > > > 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? > > > > I don't like it. In particular, the part I don't like is: > > > > + /* If the search in solib_absolute_prefix failed, and the path name is > > + absolute at this point, make it relative. (openp will try and open the > > + file according to its absolute path otherwise, which is not what we want.) > > + Affects all subsequent searches for this solib. */ > > + if (found_file < 0 && IS_DIR_SEPARATOR (in_pathname[0])) > > + in_pathname++; > > + > > > > I do understand Orjan's reasons for doing this, but it seems rather > > fragile to me. I think that we'd be better off doing one of the > > following: > > > > 1) Change openp()'s behavior so that it (optionally) doesn't > > attempt to open a file (which has an absolute path). I.e, > > force it to only consider the paths that we pass it. > > > > 2) Explicitly prepend solib_absolute_prefix to the path in question > > and pass that to openp(). Or, perhaps openp() doesn't even need > > to be called. Perhaps we can do the job with open(). > > If I understand correctly, that's not what he was trying to accomplish. > He was trying to have openp() search for the "absolute" path after each > member of solib-search-path. Am I wrong? You're right. (I misread part of the patch.) I just looked at the patch again. Now that I look at it some more, I think it's okay so long as Eli's concerns are addressed. Kevin