This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
[Proposal] GDB honouring RPATH in binaries.
> > 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 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, the proposal is either one or two. 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