From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24177 invoked by alias); 18 Jun 2003 19:09:09 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21773 invoked from network); 18 Jun 2003 19:08:20 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 18 Jun 2003 19:08:20 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3p2/8.9.3) with ESMTP id PAA15922; Wed, 18 Jun 2003 15:01:34 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id PAA09097; Wed, 18 Jun 2003 15:08:19 -0400 Message-ID: <019f01c335cd$0a119c80$0202040a@catdog> From: "Kris Warkentin" To: "Michael Snyder" Cc: "Kevin Buettner" , "Daniel Jacobowitz" , "Gdb@Sources.Redhat.Com" References: <09c201c33502$da555ce0$0202040a@catdog> <20030617191129.GA15099@nevyn.them.org> <09e801c33504$bd88b420$0202040a@catdog> <1030617200144.ZM31327@localhost.localdomain> <0ab001c3350d$359af2e0$0202040a@catdog> <1030617202406.ZM31423@localhost.localdomain> <3EEFAEDB.4090509@redhat.com> <005101c3353c$80077c70$2a00a8c0@dash> <1030618051511.ZM11645@localhost.localdomain> <003301c33594$3e6bccf0$2a00a8c0@dash> <008e01c335ab$72a101e0$0202040a@catdog> <3EF0B485.6050805@redhat.com> Subject: Re: Why does solib_open do what it does? Date: Wed, 18 Jun 2003 19:09:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-06/txt/msg00392.txt.bz2 > Kris Warkentin wrote: > > I believe the comment does not accurately reflect the code. Here is my > > proposal for the new comment using the search algorithm rather than search > > order: > > > > Search algorithm: > > * If there is a solib_absolute_prefix and path is absolute: > > * Search for solib_absolute_prefix/path. > > * else > > * Look for it literally (unmodified). > > * Look in SOLIB_SEARCH_PATH. > > I'm not sure -- but do you think it should be > /SOLIB_ABSOLUTE_PREFIX/SOLIB_SEARCH_PATH? > Or maybe both? The problem is that you don't have the freedom to define an arbitrary path if you always prepend solib-abs-pref to it. You can always put the full path in your solib-search-path if you need to. > > * If available, use target defined search function. > > * Look in inferior's $PATH. > > * Look in inferior's $LD_LIBRARY_PATH. > > I rather think that $PATH and $LD_LIBRARY_PATH should be native-only. > But come to think of it, do remote targets even have environment variables? > And if so -- do they inherit them from gdb / the host? If there's a > gdbserver-type situation, and if the server is able to provide the true > environment variables from the target, then yes, we should use these. > But I don't recall any gdbserver ever offering that functionality. Our pdebug remote protocol allows us to 'set qnxinheritenv true/false'. This determines whether gdb will send it's environment to the target or whether the target will inherit from the pdebug server. > > The code seems to make the meaning of solib_ABSOLUTE_prefix somewhat more > > literal. > > I think it's supposed to be literal. True. Just never thought of it that way. cheers, Kris