[Proposal] GDB honouring RPATH in binaries.

["Kris Warkentin" <kewarken at qnx dot com>]

> > 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