This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [Proposal] GDB honouring RPATH in binaries.
- From: Colin Burgess <cburgess at qnx dot com>
- To: Kris Warkentin <kewarken at qnx dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>, Paul Koning <pkoning at equallogic dot com>, kevinb at redhat dot com, gdb at sources dot redhat dot com
- Date: Fri, 21 Feb 2003 14:16:40 -0500 (EST)
- Subject: Re: [Proposal] GDB honouring RPATH in binaries.
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 at qnx dot com