Re: [Proposal] GDB honouring RPATH in binaries.

Colin Burgess
2003-02-21T19:18:32Z

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