From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16422 invoked by alias); 21 Feb 2003 18:30:44 -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 16415 invoked from network); 21 Feb 2003 18:30:44 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 21 Feb 2003 18:30:44 -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 NAA17230; Fri, 21 Feb 2003 13:18:54 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id NAA15735; Fri, 21 Feb 2003 13:30:44 -0500 Message-ID: <023401c2d9d7$5441ce30$0202040a@catdog> From: "Kris Warkentin" To: "Kris Warkentin" , "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> Subject: [Proposal] GDB honouring RPATH in binaries. Date: Fri, 21 Feb 2003 18:30: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/msg00472.txt.bz2 > > Yeah, I used to see this a lot too (until we made solib-absolute-prefix > > automatic in our tools). Unfortunately there is no clear hook to > > figure out if a target is remote or local; and a lot of people actually > > do use gdbserver to talk to localhost... and then there's no way to > > know if it's the same root or not. > > Aha. Looks like our loader just fills in the basename of the lib it finds. > That explains why we need so much initialization of solib-search-path and so > on. I'm going to get our kernel guy to change that so that we can just use > solib-absolute-prefix. This doesn't work for us. The situation is that there might be no clear link between the host and target directory structures. In general, all our libs wind up in /proc/boot on the target image so when the loader fills in 'libc.so' rather than '/proc/boot/libc.so', it's a benefit since we can use solib-search-path to find $QNX_TARGET/$CPU/lib/libc.so, regardless of host. So, we're stuck with initializing solib-search-path. The problem with this is that if the user needs another path in there (as in the RPATH situation), he has no way of appending to solib-search-path. It's either set or show. This makes for ugly cut and paste and general unfriendlyness. So, I have two potential solutions: 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. 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 Any comments? Kris