From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20471 invoked by alias); 21 Feb 2003 19:55:59 -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 20463 invoked from network); 21 Feb 2003 19:55:59 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 21 Feb 2003 19:55:59 -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 OAA20397; Fri, 21 Feb 2003 14:44:08 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id OAA28706; Fri, 21 Feb 2003 14:55:58 -0500 Message-ID: <02e001c2d9e3$3ca030d0$0202040a@catdog> From: "Kris Warkentin" To: "Kevin Buettner" , "Daniel Jacobowitz" , "Paul Koning" Cc: , , "Colin Burgess" References: <0db801c2d914$78f80a50$0202040a@catdog> <1030220193301.ZM10611@localhost.localdomain> <20030220194049.GA19653@nevyn.them.org> <001301c2d918$894ef1d0$0202040a@catdog> <20030220194852.GA20424@nevyn.them.org> <002701c2d919$d07edce0$0202040a@catdog> <1030220195833.ZM10783@localhost.localdomain> <15957.17196.501000.893848@gargle.gargle.HOWL> <20030220201032.GA21694@nevyn.them.org> <00e001c2d9be$616ca940$0202040a@catdog> <023401c2d9d7$5441ce30$0202040a@catdog> <1030221191915.ZM15926@localhost.localdomain> Subject: Re: [Proposal] GDB honouring RPATH in binaries. Date: Fri, 21 Feb 2003 19:55: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/msg00481.txt.bz2 > I still find myself confused as to why your loader only wants to fill > in the basename. Having an absolute path won't preclude using > solib-search-path. And it will certainly make things easier when you > have an accurate target image residing (somewhere) on the host so that you > can use solib-absolute-prefix. Like I said, typically when one makes a QNX boot image, almost everything (libs, binaries, etc.) winds up in /proc/boot. So the loader wouldn't be reporting /lib/libc.so or whatever but /proc/boot/libc.so. This will never resolve to anything on the host because the host has libs in $QNX_TARGET/$CPU/lib, usr/lib, etc. We don't make any requirement of target filesystem layout resembling host in any way. Note also that even in self hosted, apps will use /proc/boot/libc.so. This is a problem because our image making tool (mkifs) strips binaries down to just an executable view with no section information. This allows execute-in-place on flash and other memory type being used as filesystems. The problem then arises that elf_locate_base() in solib-svr4.c uses section names to find the .dynamic for the DT_DEBUG entry. This is incorrect because it requires section information. It should be looking for the PT_DYNAMIC segment and using that to find the solib base. > > One: We could add something like 'vendor-solib-search-path' which could be > > searched so that solib-search-path can be left for the user. Then vendors > > can just initialize v-s-s-p and users don't have to worry. > > I'm not in favor of this. Not keen on it myself. > > Two: provide a mechanism to append strings to gdb variables such as > > solib-search-path which might be useful in other situations. A really nice > > implementation would be some form of variable expansion, ie: > > > > set solib-search-path $solib-search-path:/home/foo > > I think something like this has been discussed before. It sounds like > a good idea to me. Good general purpose idea but still not super convenient for users. I think my suggestion number three is the best. I've almost got it implemented. Kris