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