[Proposal] GDB honouring RPATH in binaries.

["Kris Warkentin" <kewarken@qnx.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 on the target image 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, 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

Any comments?

Kris