Re: [Proposal] GDB honouring RPATH in binaries.

[Colin Burgess <cburgess@qnx.com>]

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