From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22480 invoked by alias); 27 Nov 2001 19:15:56 -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 22428 invoked from network); 27 Nov 2001 19:15:48 -0000 Received: from unknown (HELO miranda.axis.se) (193.13.178.2) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 19:15:48 -0000 Received: from ironmaiden.axis.se (ironmaiden.axis.se [10.13.8.120]) by miranda.axis.se (8.12.1/8.12.1/Debian -2) with ESMTP id fARJFiXX015717; Tue, 27 Nov 2001 20:15:44 +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 UAA12411; Tue, 27 Nov 2001 20:15:44 +0100 X-Authentication-Warning: ironmaiden.axis.se: Host localhost [127.0.0.1] claimed to be axis.com Message-ID: <3C03E660.B33DF385@axis.com> Date: Wed, 14 Nov 2001 18:33: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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00290.txt.bz2 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). > solib-search-path is colon separated; why is this a problem? No problem; my bad. I didn't know solib-search-path could be colon separated, though I see that now in openp. -- 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: Tue, 27 Nov 2001 11:15:00 -0000 Message-ID: <3C03E660.B33DF385@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> X-SW-Source: 2001-11/msg00505.html Message-ID: <20011127111500.yYU_1pV0UqTiCTk9-nP5UZFIPdzpWxm8mKGrPxmPOXU@z> 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). > solib-search-path is colon separated; why is this a problem? No problem; my bad. I didn't know solib-search-path could be colon separated, though I see that now in openp. -- Orjan Friberg Axis Communications AB