Re: [Proposal] GDB honouring RPATH in binaries.

["Kris Warkentin" <kewarken@qnx.com>]

> I still find myself confused as to why your loader only wants to fill
> in the basename.  Having an absolute path won't preclude using
> solib-search-path.  And it will certainly make things easier when you
> have an accurate target image residing (somewhere) on the host so that you
> can use solib-absolute-prefix.

Like I said, typically when one makes a QNX boot image, almost everything
(libs, binaries, etc.) winds up in /proc/boot.  So the loader wouldn't be
reporting /lib/libc.so or whatever but /proc/boot/libc.so.  This will never
resolve to anything on the host because the host has libs in
$QNX_TARGET/$CPU/lib, usr/lib, etc.  We don't make any requirement of target
filesystem layout resembling host in any way.

Note also that even in self hosted, apps will use /proc/boot/libc.so.  This
is a problem because our image making tool (mkifs) strips binaries down to
just an executable view with no section information.  This allows
execute-in-place on flash and other memory type being used as filesystems.
The problem then arises that elf_locate_base() in solib-svr4.c uses section
names to find the .dynamic for the DT_DEBUG entry.  This is incorrect
because it requires section information.  It should be looking for the
PT_DYNAMIC segment and using that to find the solib base.

> > 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.
>
> I'm not in favor of this.

Not keen on it myself.

> > 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
>
> I think something like this has been discussed before.  It sounds like
> a good idea to me.

Good general purpose idea but still not super convenient for users.  I think
my suggestion number three is the best.  I've almost got it implemented.

Kris