From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29312 invoked by alias); 21 Feb 2003 19:18:32 -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 29280 invoked from network); 21 Feb 2003 19:18:30 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 21 Feb 2003 19:18:30 -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 OAA19088; Fri, 21 Feb 2003 14:06:40 -0500 Received: from node109 (node109 [10.0.0.109]) by smtp.ott.qnx.com (8.8.8/8.6.12) with ESMTP id OAA02276; Fri, 21 Feb 2003 14:18:30 -0500 Date: Fri, 21 Feb 2003 19:18:00 -0000 From: Colin Burgess X-Sender: cburgess@node109.ott.qnx.com To: Kris Warkentin cc: Daniel Jacobowitz , Paul Koning , kevinb@redhat.com, gdb@sources.redhat.com Subject: Re: [Proposal] GDB honouring RPATH in binaries. In-Reply-To: <02b201c2d9dd$741f8de0$0202040a@catdog> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-02/txt/msg00478.txt.bz2 One thing I've never liked about the solib stuff is the lack of control the user has. Why can I say libc.so.2 = /home/cburgess/test/libc.so.2 libm.so.2 = /x86/lib/libm.so.2 and have gdb accept this fact?!! :v) And what would be so wrong about something like (gdb) info shared Looking for libc.so.2 ... found /x86/lib/libc.so.2 - accept? n please enter path to libc.so.2> :v) On Fri, 21 Feb 2003, Kris Warkentin wrote: > > 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 > > > > Ooh ooh....number 3 just came to mind. In solib_open(), we go through a > bunch of, "Lib not found yet? Okay, try this. Still not found? Okay, try > this". > > We could just make a target_ops solib_open_hook that returns a fd to the lib > in some vendor/target defined way. Then, in solib_open(), we just check to > see if the hook is there and try to open the lib with that. This would work > really well because then we can adjust on the fly to endian issues, etc. > ie. $QNX_TARGET/armbe or armle. > > Kris > > -- cburgess@qnx.com