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