From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21399 invoked by alias); 20 Feb 2003 19:41:13 -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 21383 invoked from network); 20 Feb 2003 19:41:12 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 20 Feb 2003 19:41:12 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id OAA13051; Thu, 20 Feb 2003 14:29:28 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id OAA09460; Thu, 20 Feb 2003 14:41:12 -0500 Message-ID: <000701c2d918$02918950$0202040a@catdog> From: "Kris Warkentin" To: "Kevin Buettner" , References: <0db801c2d914$78f80a50$0202040a@catdog> <1030220193301.ZM10611@localhost.localdomain> Subject: Re: GDB honouring RPATH in binaries. Date: Thu, 20 Feb 2003 19:41: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.1106 X-SW-Source: 2003-02/txt/msg00430.txt.bz2 > > I've been having a debate with some coworkers about whether or not gdb > > should use the rpath in an elf binary to find shared libs if it has been > > set. The runtime loader checks LD_LIBRARY_PATH, RPATH and CS_LIBPATH in > > that order and the proposal was that gdb should do the same thing. > > > > The problem I have with this is in the remote case. This might make perfect > > sense on a self-hosted debugger but if targetting a remote machine, the > > RPATH might not make any logical mapping onto the host machine's filesystem. > > It might be possible to come up with some sort of heuristic using > > solib-absolute-prefix as a base but I don't think there's any reliable way > > to make use of this info if not self hosted. > > > > Any thoughts? > > The other problem that I see is that the procedures used to resolve > the location of a dynamic library will vary depending upon the runtime > loader. E.g, on Linux, I am pretty sure that RPATH supercedes > LD_LIBRARY_PATH. Good point. > It may make sense to have a osabi dependent method for doing this > resolution. Or maybe this machinery should be tied to the solib > back end. (That way if you had a qnx back end, it would get used > automatically.) > > With regard to the remote case, I would have thought that simply > prepending solib-absolute-prefix would give the correct results. Well, let's say I upload my program and libs to /tmp on the remote with the binary's RPATH set to /tmp. I'm debugging on Cygwin in /home/kewarken/test. My solib-absolute-prefix and solib-search-path are based in c:\QNXsdk\target\qnx6 (where all the libs are stored). This is why I'm not convinced that there's any nice way to use RPATH in the remote case. cheers, Kris