From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15255 invoked by alias); 27 Nov 2001 23:44:49 -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 15190 invoked from network); 27 Nov 2001 23:44:48 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 23:44:48 -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 PAA05825; Tue, 27 Nov 2001 15:44:46 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.9.3/8.9.3) id QAA13448; Tue, 27 Nov 2001 16:44:28 -0700 Date: Thu, 15 Nov 2001 08:00:00 -0000 From: Kevin Buettner Message-ID: <1011127234428.ZM13447@ocotillo.lan> In-Reply-To: Daniel Jacobowitz "Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)" (Nov 27, 2:29pm) 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-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Daniel Jacobowitz , Orjan Friberg Subject: Re: [RFC]: Solib search (Was: Re: Cross solib support; continued) Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2001-11/txt/msg00302.txt.bz2 Message-ID: <20011115080000.RKc5z1ZvLfOG6lJOfSvN8ABZ4Q2jCDfPjCVfwTpU5Ws@z> 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(). Of these two, I like the second better. Kevin