From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23717 invoked by alias); 18 Jun 2003 20:17:58 -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 23709 invoked from network); 18 Jun 2003 20:17:58 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 18 Jun 2003 20:17:58 -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 QAA21108; Wed, 18 Jun 2003 16:11:12 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id QAA07374; Wed, 18 Jun 2003 16:17:57 -0400 Message-ID: <01e301c335d6$c4798e80$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> <019f01c335cd$0a119c80$0202040a@catdog> <3EF0C723.3000109@redhat.com> Subject: Re: Why does solib_open do what it does? Date: Wed, 18 Jun 2003 20:17: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/msg00398.txt.bz2 > >>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. > > Cool, and I presume you can then read them back. > In that case, (assuming the child inherits from the target side server), > wouldn't you want LD_LIBRARY_PATH to be searched? If the linker-loader > picks up libc from one place, but gdb picks it up from someplace else, > you're hosed. Nope. Say I've got a windows host. My libs are in $QNX_TARGET/$CPU/usr/lib (ie. c:\QNXsdk\target\qnx6\ppcbe\usr\lib). On my target, LD_LIBRARY_PATH is relative to the root, on my host, they're relative to $QNX_TARGET/$CPU. This is where the target defined search function comes in. We construct a search path using $QNX_TARGET/$CPU as a base and search from there. Actually, we set solib-absolute-prefix to $QNX_TARGET/$CPU as well so in many cases it gets found by the very first check. cheers, Kris