GDB honouring RPATH in binaries.

GDB honouring RPATH in binaries.

[Kris Warkentin]

I've been having a debate with some coworkers about whether or not gdb
should use the rpath in an elf binary to find shared libs if it has been
set.  The runtime loader checks LD_LIBRARY_PATH, RPATH and CS_LIBPATH in
that order and the proposal was that gdb should do the same thing.

The problem I have with this is in the remote case.  This might make perfect
sense on a self-hosted debugger but if targetting a remote machine, the
RPATH might not make any logical mapping onto the host machine's filesystem.
It might be possible to come up with some sort of heuristic using
solib-absolute-prefix as a base but I don't think there's any reliable way
to make use of this info if not self hosted.

Any thoughts?

Kris

Re: GDB honouring RPATH in binaries.

[Kevin Buettner]

On Feb 20,  2:15pm, Kris Warkentin wrote:

> I've been having a debate with some coworkers about whether or not gdb
> should use the rpath in an elf binary to find shared libs if it has been
> set.  The runtime loader checks LD_LIBRARY_PATH, RPATH and CS_LIBPATH in
> that order and the proposal was that gdb should do the same thing.
> 
> The problem I have with this is in the remote case.  This might make perfect
> sense on a self-hosted debugger but if targetting a remote machine, the
> RPATH might not make any logical mapping onto the host machine's filesystem.
> It might be possible to come up with some sort of heuristic using
> solib-absolute-prefix as a base but I don't think there's any reliable way
> to make use of this info if not self hosted.
> 
> Any thoughts?

The other problem that I see is that the procedures used to resolve
the location of a dynamic library will vary depending upon the runtime
loader.  E.g, on Linux, I am pretty sure that RPATH supercedes
LD_LIBRARY_PATH.

It may make sense to have a osabi dependent method for doing this
resolution.  Or maybe this machinery should be tied to the solib
back end.  (That way if you had a qnx back end, it would get used
automatically.)

With regard to the remote case, I would have thought that simply
prepending solib-absolute-prefix would give the correct results.

Kevin

Re: GDB honouring RPATH in binaries.

[Daniel Jacobowitz]

On Thu, Feb 20, 2003 at 12:33:01PM -0700, Kevin Buettner wrote:
> On Feb 20,  2:15pm, Kris Warkentin wrote:
> 
> > I've been having a debate with some coworkers about whether or not gdb
> > should use the rpath in an elf binary to find shared libs if it has been
> > set.  The runtime loader checks LD_LIBRARY_PATH, RPATH and CS_LIBPATH in
> > that order and the proposal was that gdb should do the same thing.
> > 
> > The problem I have with this is in the remote case.  This might make perfect
> > sense on a self-hosted debugger but if targetting a remote machine, the
> > RPATH might not make any logical mapping onto the host machine's filesystem.
> > It might be possible to come up with some sort of heuristic using
> > solib-absolute-prefix as a base but I don't think there's any reliable way
> > to make use of this info if not self hosted.
> > 
> > Any thoughts?
> 
> The other problem that I see is that the procedures used to resolve
> the location of a dynamic library will vary depending upon the runtime
> loader.  E.g, on Linux, I am pretty sure that RPATH supercedes
> LD_LIBRARY_PATH.
> 
> It may make sense to have a osabi dependent method for doing this
> resolution.  Or maybe this machinery should be tied to the solib
> back end.  (That way if you had a qnx back end, it would get used
> automatically.)
> 
> With regard to the remote case, I would have thought that simply
> prepending solib-absolute-prefix would give the correct results.

Question: when do we need to find shared libraries that we can't use a
full path + solib-absolute-prefix, where RPATH would be in the least
useful?  RPATH only matters when you have multiple places you could
find the library and are interested in which one you got; if there is a
mapping between target and host filesystems, it should be
solib-absolute-prefix only.

We generally get full pathnames of loaded modules from the dynamic
linker, and use that.  Is this a problem for QNX?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB honouring RPATH in binaries.

[Kris Warkentin]

> > I've been having a debate with some coworkers about whether or not gdb
> > should use the rpath in an elf binary to find shared libs if it has been
> > set.  The runtime loader checks LD_LIBRARY_PATH, RPATH and CS_LIBPATH in
> > that order and the proposal was that gdb should do the same thing.
> >
> > The problem I have with this is in the remote case.  This might make
perfect
> > sense on a self-hosted debugger but if targetting a remote machine, the
> > RPATH might not make any logical mapping onto the host machine's
filesystem.
> > It might be possible to come up with some sort of heuristic using
> > solib-absolute-prefix as a base but I don't think there's any reliable
way
> > to make use of this info if not self hosted.
> >
> > Any thoughts?
>
> The other problem that I see is that the procedures used to resolve
> the location of a dynamic library will vary depending upon the runtime
> loader.  E.g, on Linux, I am pretty sure that RPATH supercedes
> LD_LIBRARY_PATH.

Good point.

> It may make sense to have a osabi dependent method for doing this
> resolution.  Or maybe this machinery should be tied to the solib
> back end.  (That way if you had a qnx back end, it would get used
> automatically.)
>
> With regard to the remote case, I would have thought that simply
> prepending solib-absolute-prefix would give the correct results.

Well, let's say I upload my program and libs to /tmp on the remote with the
binary's RPATH set to /tmp.  I'm debugging on Cygwin in /home/kewarken/test.
My solib-absolute-prefix and solib-search-path are based in
c:\QNXsdk\target\qnx6 (where all the libs are stored).  This is why I'm not
convinced that there's any nice way to use RPATH in the remote case.

cheers,

Kris

Re: GDB honouring RPATH in binaries.

[Kris Warkentin]

> Question: when do we need to find shared libraries that we can't use a
> full path + solib-absolute-prefix, where RPATH would be in the least
> useful?  RPATH only matters when you have multiple places you could
> find the library and are interested in which one you got; if there is a
> mapping between target and host filesystems, it should be
> solib-absolute-prefix only.
>
> We generally get full pathnames of loaded modules from the dynamic
> linker, and use that.  Is this a problem for QNX?

In the remote case I suppose it is.  The linker on the remote will have
loaded /lib/libc.so.2 or some such but on the host, that will be
$QNX_TARGET/$CPU/lib/libc.so.2.  Hence solib-absolute-prefix being set to
$QNX_TARGET/$CPU.  I'm just looking for better ways to get this all to work
together with a minimum of fuss for the end user.

cheers,

Kris

Re: GDB honouring RPATH in binaries.

[Daniel Jacobowitz]

On Thu, Feb 20, 2003 at 02:44:52PM -0500, Kris Warkentin wrote:
> > Question: when do we need to find shared libraries that we can't use a
> > full path + solib-absolute-prefix, where RPATH would be in the least
> > useful?  RPATH only matters when you have multiple places you could
> > find the library and are interested in which one you got; if there is a
> > mapping between target and host filesystems, it should be
> > solib-absolute-prefix only.
> >
> > We generally get full pathnames of loaded modules from the dynamic
> > linker, and use that.  Is this a problem for QNX?
> 
> In the remote case I suppose it is.  The linker on the remote will have
> loaded /lib/libc.so.2 or some such but on the host, that will be
> $QNX_TARGET/$CPU/lib/libc.so.2.  Hence solib-absolute-prefix being set to
> $QNX_TARGET/$CPU.  I'm just looking for better ways to get this all to work
> together with a minimum of fuss for the end user.

I guess I don't see the problem.  If we have solib-absolute-prefix set,
and we retrieve the string "/lib/libc.so.2" from the remote target...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB honouring RPATH in binaries.

[Kevin Buettner]

Kris,

Could you clarify something?  When you refer to "RPATH", are you referring
to an environment variable or the search path found in an executable's
dynamic section (tagged with DT_RPATH)?

(I was thinking you meant the latter, but I want to make sure we're
on the same page.)

Kevin

Re: GDB honouring RPATH in binaries.

[Kevin Buettner]

On Feb 20,  2:40pm, Daniel Jacobowitz wrote:

> We generally get full pathnames of loaded modules from the dynamic
> linker, and use that.

Good point.  I'd forgotten about that.

> Is this a problem for QNX?

Good question too.

Re: GDB honouring RPATH in binaries.

[Kris Warkentin]

> Could you clarify something?  When you refer to "RPATH", are you referring
> to an environment variable or the search path found in an executable's
> dynamic section (tagged with DT_RPATH)?
> 
> (I was thinking you meant the latter, but I want to make sure we're
> on the same page.)

Yes, we are on the same page.  I'm talking about the elf DT_RPATH.

Kris

Re: GDB honouring RPATH in binaries.

[Kris Warkentin]

> On Thu, Feb 20, 2003 at 02:44:52PM -0500, Kris Warkentin wrote:
> > > Question: when do we need to find shared libraries that we can't use a
> > > full path + solib-absolute-prefix, where RPATH would be in the least
> > > useful?  RPATH only matters when you have multiple places you could
> > > find the library and are interested in which one you got; if there is
a
> > > mapping between target and host filesystems, it should be
> > > solib-absolute-prefix only.
> > >
> > > We generally get full pathnames of loaded modules from the dynamic
> > > linker, and use that.  Is this a problem for QNX?
> >
> > In the remote case I suppose it is.  The linker on the remote will have
> > loaded /lib/libc.so.2 or some such but on the host, that will be
> > $QNX_TARGET/$CPU/lib/libc.so.2.  Hence solib-absolute-prefix being set
to
> > $QNX_TARGET/$CPU.  I'm just looking for better ways to get this all to
work
> > together with a minimum of fuss for the end user.
>
> I guess I don't see the problem.  If we have solib-absolute-prefix set,
> and we retrieve the string "/lib/libc.so.2" from the remote target...

You're preaching to the choir. ;-)  I'm just trying to form an intelligent
argument for those in my company who want to use RPATH.  In solib_open(), we
search the inferior's LD_LIBRARY_PATH and PATH as a fallback so I wonder if
there would be any harm in at least looking at the RPATH?  Perhaps if we
just appended it to solib-search-path or one of the others?  I dunno.
That's why I'm asking.

Kris

Re: GDB honouring RPATH in binaries.

[Kevin Buettner]

On Feb 20,  2:41pm, Kris Warkentin wrote:

> > With regard to the remote case, I would have thought that simply
> > prepending solib-absolute-prefix would give the correct results.
> 
> Well, let's say I upload my program and libs to /tmp on the remote with the
> binary's RPATH set to /tmp.  I'm debugging on Cygwin in /home/kewarken/test.
> My solib-absolute-prefix and solib-search-path are based in
> c:\QNXsdk\target\qnx6 (where all the libs are stored).  This is why I'm not
> convinced that there's any nice way to use RPATH in the remote case.

I see what you mean.  Unless you're using an NFS mount, it's unlikely
for the sys-root on the host to contain the stuff you've just uploaded
to /tmp.

In this case, I think it would make sense to use solib-search-path
to find the libraries that you've uploaded to /tmp.

Kevin

Re: GDB honouring RPATH in binaries.

[Kevin Buettner]

On Feb 20,  2:54pm, Kris Warkentin wrote:

> > On Thu, Feb 20, 2003 at 02:44:52PM -0500, Kris Warkentin wrote:
> > > > Question: when do we need to find shared libraries that we can't use a
> > > > full path + solib-absolute-prefix, where RPATH would be in the least
> > > > useful?  RPATH only matters when you have multiple places you could
> > > > find the library and are interested in which one you got; if there is
> a
> > > > mapping between target and host filesystems, it should be
> > > > solib-absolute-prefix only.
> > > >
> > > > We generally get full pathnames of loaded modules from the dynamic
> > > > linker, and use that.  Is this a problem for QNX?
> > >
> > > In the remote case I suppose it is.  The linker on the remote will have
> > > loaded /lib/libc.so.2 or some such but on the host, that will be
> > > $QNX_TARGET/$CPU/lib/libc.so.2.  Hence solib-absolute-prefix being set
> to
> > > $QNX_TARGET/$CPU.  I'm just looking for better ways to get this all to
> work
> > > together with a minimum of fuss for the end user.
> >
> > I guess I don't see the problem.  If we have solib-absolute-prefix set,
> > and we retrieve the string "/lib/libc.so.2" from the remote target...
> 
> You're preaching to the choir. ;-)  I'm just trying to form an intelligent
> argument for those in my company who want to use RPATH.  In solib_open(), we
> search the inferior's LD_LIBRARY_PATH and PATH as a fallback so I wonder if
> there would be any harm in at least looking at the RPATH?  Perhaps if we
> just appended it to solib-search-path or one of the others?  I dunno.
> That's why I'm asking.

For remote targets, you must have solib-absolute-prefix set.  Searching
host libraries (whether found via RPATH or some other means) is almost
invariably wrong.

Kevin

Re: GDB honouring RPATH in binaries.

[Kris Warkentin]

> > > With regard to the remote case, I would have thought that simply
> > > prepending solib-absolute-prefix would give the correct results.
> >
> > Well, let's say I upload my program and libs to /tmp on the remote with
the
> > binary's RPATH set to /tmp.  I'm debugging on Cygwin in
/home/kewarken/test.
> > My solib-absolute-prefix and solib-search-path are based in
> > c:\QNXsdk\target\qnx6 (where all the libs are stored).  This is why I'm
not
> > convinced that there's any nice way to use RPATH in the remote case.
>
> I see what you mean.  Unless you're using an NFS mount, it's unlikely
> for the sys-root on the host to contain the stuff you've just uploaded
> to /tmp.
>
> In this case, I think it would make sense to use solib-search-path
> to find the libraries that you've uploaded to /tmp.

Yes.  This is really just a case of trying to automate this so that the user
has less trouble.  You have no idea how many tech support calls we get which
are solved by, "make sure that gdb can find everything it needs".  From what
I understand, RPATH is supposed to be THE ordained way of making sure that
the linker can find it's libs so perhaps we need to add one more case to
solib_open() where it looks through RPATH.  I'm thinking that it can't hurt
and might help.  Certainly it will be helpful on native debuggers.

Kris

Re: GDB honouring RPATH in binaries.

[Daniel Jacobowitz]

On Thu, Feb 20, 2003 at 02:54:01PM -0500, Kris Warkentin wrote:
> > On Thu, Feb 20, 2003 at 02:44:52PM -0500, Kris Warkentin wrote:
> > > > Question: when do we need to find shared libraries that we can't use a
> > > > full path + solib-absolute-prefix, where RPATH would be in the least
> > > > useful?  RPATH only matters when you have multiple places you could
> > > > find the library and are interested in which one you got; if there is
> a
> > > > mapping between target and host filesystems, it should be
> > > > solib-absolute-prefix only.
> > > >
> > > > We generally get full pathnames of loaded modules from the dynamic
> > > > linker, and use that.  Is this a problem for QNX?
> > >
> > > In the remote case I suppose it is.  The linker on the remote will have
> > > loaded /lib/libc.so.2 or some such but on the host, that will be
> > > $QNX_TARGET/$CPU/lib/libc.so.2.  Hence solib-absolute-prefix being set
> to
> > > $QNX_TARGET/$CPU.  I'm just looking for better ways to get this all to
> work
> > > together with a minimum of fuss for the end user.
> >
> > I guess I don't see the problem.  If we have solib-absolute-prefix set,
> > and we retrieve the string "/lib/libc.so.2" from the remote target...
> 
> You're preaching to the choir. ;-)  I'm just trying to form an intelligent
> argument for those in my company who want to use RPATH.  In solib_open(), we
> search the inferior's LD_LIBRARY_PATH and PATH as a fallback so I wonder if
> there would be any harm in at least looking at the RPATH?  Perhaps if we
> just appended it to solib-search-path or one of the others?  I dunno.
> That's why I'm asking.

IMVHO, this is what should be happening in your setup:
 - search $solib-absolute-prefix/$full-path-from-target
 - search $solib-search-path for $basename-from-target

If you've uploaded it somewhere (/tmp) other than the normal location,
then it's your responsibility to make sure solib-search-path works.  I
don't see the point in honoring rpath.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB honouring RPATH in binaries.

[Kevin Buettner]

On Feb 20, 12:58pm, Kevin Buettner wrote:

> For remote targets, you must have solib-absolute-prefix set.  Searching
> host libraries (whether found via RPATH or some other means) is almost
> invariably wrong.

BTW, the sysroot stuff that Daniel recently added makes this
a good deal less painful for the user.

Kevin

Re: GDB honouring RPATH in binaries.

[Kris Warkentin]

> > For remote targets, you must have solib-absolute-prefix set.  Searching
> > host libraries (whether found via RPATH or some other means) is almost
> > invariably wrong.
> 
> BTW, the sysroot stuff that Daniel recently added makes this
> a good deal less painful for the user.

Not familiar with this.  Is there some documentation somewhere?

Kris

Re: GDB honouring RPATH in binaries.

[Daniel Jacobowitz]

On Thu, Feb 20, 2003 at 02:59:34PM -0500, Kris Warkentin wrote:
> > > > With regard to the remote case, I would have thought that simply
> > > > prepending solib-absolute-prefix would give the correct results.
> > >
> > > Well, let's say I upload my program and libs to /tmp on the remote with
> the
> > > binary's RPATH set to /tmp.  I'm debugging on Cygwin in
> /home/kewarken/test.
> > > My solib-absolute-prefix and solib-search-path are based in
> > > c:\QNXsdk\target\qnx6 (where all the libs are stored).  This is why I'm
> not
> > > convinced that there's any nice way to use RPATH in the remote case.
> >
> > I see what you mean.  Unless you're using an NFS mount, it's unlikely
> > for the sys-root on the host to contain the stuff you've just uploaded
> > to /tmp.
> >
> > In this case, I think it would make sense to use solib-search-path
> > to find the libraries that you've uploaded to /tmp.
> 
> Yes.  This is really just a case of trying to automate this so that the user
> has less trouble.  You have no idea how many tech support calls we get which
> are solved by, "make sure that gdb can find everything it needs".  From what
> I understand, RPATH is supposed to be THE ordained way of making sure that
> the linker can find it's libs so perhaps we need to add one more case to
> solib_open() where it looks through RPATH.  I'm thinking that it can't hurt
> and might help.  Certainly it will be helpful on native debuggers.

Certainly it should _NOT_ be helpful on native debuggers.

By the time GDB is loading a shared library, the dynamic linker has
resolved it to a full path.  This should always be the case; I don't
want to duplicate the path resolution logic of a hundred quirky OS
versions in GDB.  We shouldn't need to search RPATH.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB honouring RPATH in binaries.

[Paul Koning]

>>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:

 Kevin> For remote targets, you must have solib-absolute-prefix set.
 Kevin> Searching host libraries (whether found via RPATH or some
 Kevin> other means) is almost invariably wrong.

I'd omit "almost".  In fact, it would be useful if gdb could complain
for a remote debug when solib-absolute-prefix isn't set.  That would
eliminate a lot of confusion when people forget to set it.  When
debugging MIPS code, gdb is perfectly happy to load shared file symbol
tables from /usr/lib, even though those are x86 binaries!  The result
is utter chaos, of course.  It would be helpful if gdb prevented that
sort of simple user error.  (I suppose another way to avoid that is to
have gdb check that the shared library it's examining is at least
meant for the same processor family, and I suppose the same
endianness...)

   paul

Re: GDB honouring RPATH in binaries.

[Daniel Jacobowitz]

On Thu, Feb 20, 2003 at 03:01:52PM -0500, Kris Warkentin wrote:
> > > For remote targets, you must have solib-absolute-prefix set.  Searching
> > > host libraries (whether found via RPATH or some other means) is almost
> > > invariably wrong.
> > 
> > BTW, the sysroot stuff that Daniel recently added makes this
> > a good deal less painful for the user.
> 
> Not familiar with this.  Is there some documentation somewhere?

It's in the GDB manual now, and it also applies to LD and GCC.  For GDB
it only amounts to:

You can set the default value of @samp{solib-absolute-prefix} by using
the configure-time @samp{--with-sysroot} option.

For GCC and LD it's a great deal more thorough; it changes header
search paths, library search paths, etc.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB honouring RPATH in binaries.

[Daniel Jacobowitz]

On Thu, Feb 20, 2003 at 04:05:48PM -0500, Paul Koning wrote:
> >>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:
> 
>  Kevin> For remote targets, you must have solib-absolute-prefix set.
>  Kevin> Searching host libraries (whether found via RPATH or some
>  Kevin> other means) is almost invariably wrong.
> 
> I'd omit "almost".  In fact, it would be useful if gdb could complain
> for a remote debug when solib-absolute-prefix isn't set.  That would
> eliminate a lot of confusion when people forget to set it.  When
> debugging MIPS code, gdb is perfectly happy to load shared file symbol
> tables from /usr/lib, even though those are x86 binaries!  The result
> is utter chaos, of course.  It would be helpful if gdb prevented that
> sort of simple user error.  (I suppose another way to avoid that is to
> have gdb check that the shared library it's examining is at least
> meant for the same processor family, and I suppose the same
> endianness...)

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB honouring RPATH in binaries.

[Kris Warkentin]

> On Thu, Feb 20, 2003 at 03:01:52PM -0500, Kris Warkentin wrote:
> > > > For remote targets, you must have solib-absolute-prefix set.
Searching
> > > > host libraries (whether found via RPATH or some other means) is
almost
> > > > invariably wrong.
> > >
> > > BTW, the sysroot stuff that Daniel recently added makes this
> > > a good deal less painful for the user.
> >
> > Not familiar with this.  Is there some documentation somewhere?
>
> It's in the GDB manual now, and it also applies to LD and GCC.  For GDB
> it only amounts to:
>
> You can set the default value of @samp{solib-absolute-prefix} by using
> the configure-time @samp{--with-sysroot} option.
>
> For GCC and LD it's a great deal more thorough; it changes header
> search paths, library search paths, etc.

Ah.  I can see how that would be useful.  We have an additional difficulty
in that we support multi-endian targets (mips, arm) so our
solib-absolute-prefix could change from $QNX_TARGET/armle to
$QNX_TARGET/armbe depending on the binary we load.  We already set up our
solib-search-path and s-a-p programmatically and I may have to expand that
logic further to make it all work correctly.

cheers,

Kris

Re: GDB honouring RPATH in binaries.

[Kevin Buettner]

On Feb 20,  4:05pm, Paul Koning wrote:

> >>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:
> 
>  Kevin> For remote targets, you must have solib-absolute-prefix set.
>  Kevin> Searching host libraries (whether found via RPATH or some
>  Kevin> other means) is almost invariably wrong.
> 
> I'd omit "almost".  In fact, it would be useful if gdb could complain
> for a remote debug when solib-absolute-prefix isn't set.  That would
> eliminate a lot of confusion when people forget to set it.  When
> debugging MIPS code, gdb is perfectly happy to load shared file symbol
> tables from /usr/lib, even though those are x86 binaries!  The result
> is utter chaos, of course.  It would be helpful if gdb prevented that
> sort of simple user error.  (I suppose another way to avoid that is to
> have gdb check that the shared library it's examining is at least
> meant for the same processor family, and I suppose the same
> endianness...)

Another somewhat more subtle problem is when the user does have
solib-absolute-prefix set, but, somehow, a mismatch between the
libraries stored in the host's sysroot and the target occurs.

It might be useful to compare the bytes in the readonly sections as
found on the target and host's sysroot to make sure that the file
is likely the same.  (I think Daniel J mentioned something about
doing a checksum a while back.)

Kevin

Re: GDB honouring RPATH in binaries.

[Kris Warkentin]

> >  Kevin> For remote targets, you must have solib-absolute-prefix set.
> >  Kevin> Searching host libraries (whether found via RPATH or some
> >  Kevin> other means) is almost invariably wrong.
> >
> > I'd omit "almost".  In fact, it would be useful if gdb could complain
> > for a remote debug when solib-absolute-prefix isn't set.  That would
> > eliminate a lot of confusion when people forget to set it.  When
> > debugging MIPS code, gdb is perfectly happy to load shared file symbol
> > tables from /usr/lib, even though those are x86 binaries!  The result
> > is utter chaos, of course.  It would be helpful if gdb prevented that
> > sort of simple user error.  (I suppose another way to avoid that is to
> > have gdb check that the shared library it's examining is at least
> > meant for the same processor family, and I suppose the same
> > endianness...)
>
> 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.

cheers,

Kris

[Proposal] GDB honouring RPATH in binaries.

[Kris Warkentin]

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

[Proposal] GDB honouring RPATH in binaries.

[Kris Warkentin]

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

Re: [Proposal] GDB honouring RPATH in binaries.

[Kris Warkentin]

Oops...sorry about that.  For some reason it got sent before I finished
editing it without my noticing.

Kris

Re: [Proposal] GDB honouring RPATH in binaries.

[Kris Warkentin]

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

Ooh ooh....number 3 just came to mind.  In solib_open(), we go through a
bunch of, "Lib not found yet? Okay, try this.  Still not found?  Okay, try
this".

We could just make a target_ops solib_open_hook that returns a fd to the lib
in some vendor/target defined way.  Then, in solib_open(), we just check to
see if the hook is there and try to open the lib with that.  This would work
really well because then we can adjust on the fly to endian issues, etc.
ie. $QNX_TARGET/armbe or armle.

Kris

Re: [Proposal] GDB honouring RPATH in binaries.

[Colin Burgess]

One thing I've never liked about the solib stuff is the lack of control the
user has.

Why can I say

libc.so.2 = /home/cburgess/test/libc.so.2
libm.so.2 = /x86/lib/libm.so.2

and have gdb accept this fact?!! :v)

And what would be so wrong about something like

(gdb) info shared
Looking for libc.so.2 ... found /x86/lib/libc.so.2 - accept?
n
please enter path to libc.so.2> 

:v)

On Fri, 21 Feb 2003, Kris Warkentin wrote:

> > 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
> >
> 
> Ooh ooh....number 3 just came to mind.  In solib_open(), we go through a
> bunch of, "Lib not found yet? Okay, try this.  Still not found?  Okay, try
> this".
> 
> We could just make a target_ops solib_open_hook that returns a fd to the lib
> in some vendor/target defined way.  Then, in solib_open(), we just check to
> see if the hook is there and try to open the lib with that.  This would work
> really well because then we can adjust on the fly to endian issues, etc.
> ie. $QNX_TARGET/armbe or armle.
> 
> Kris
> 
> 

-- 
cburgess@qnx.com

Re: [Proposal] GDB honouring RPATH in binaries.

[Kevin Buettner]

On Feb 21,  1:30pm, Kris Warkentin wrote:

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

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.

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

I'm not in favor of this.

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

Kevin

Re: [Proposal] GDB honouring RPATH in binaries.

[Colin Burgess]

On Fri, 21 Feb 2003, Kevin Buettner wrote:

> On Feb 21,  1:30pm, Kris Warkentin wrote:
> 
> > > 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.
> 
> 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.

There's no particular reason that I can see.  I'm looking into adding it.
However, the fact remains that all released versions of QNX don't have
the fullpath...

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

Yes, I think this is a good idea too.

-- 
cburgess@qnx.com

Re: [Proposal] GDB honouring RPATH in binaries.

[Kris Warkentin]

> 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

Re: [Proposal] GDB honouring RPATH in binaries.

[Kris Warkentin]

Okay, there's a patch down below.  The nice thing is it lets me create the
following function and then assign it to TARGET_SO_FIND_AND_OPEN_SOLIB in my
initialization code.  I've tested it and it removes my requirements to
monkey with solib-search-path.

cheers,

Kris

/* example of finding our solibs */
int
nto_find_and_open_solib (char *solib, unsigned o_flag, char **temp_pathname)
{
  char *buf, arch_path[PATH_MAX], *nto_root, *endian;
  const char *arch;
  char *path_fmt = "%s/lib:%s/usr/lib:%s/usr/photon/lib\
:%s/usr/photon/dll:%s/lib/dll";

  nto_root = nto_target ();
  if (strcmp (TARGET_ARCHITECTURE->arch_name, "i386") == 0)
    {
      arch = "x86";
      endian = "";
    }
  else if (strcmp (TARGET_ARCHITECTURE->arch_name, "rs6000") == 0)
    {
      arch = "ppc";
      endian = "be";
    }
  else
    {
      arch = TARGET_ARCHITECTURE->arch_name;
      endian = TARGET_BYTE_ORDER == BFD_ENDIAN_BIG ? "be" : "le";
    }

  sprintf (arch_path, "%s/%s%s", nto_root, arch, endian);

  buf = alloca (strlen(path_fmt) + arch_path * 5 + 1);
  sprintf (buf, path_fmt, arch_path, arch_path, arch_path, arch_path,
arch_path);

  return openp(buf, 1, solib, o_flags, 0, temp_pathname);
}



Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.53
diff -c -r1.53 solib.c
*** solib.c 18 Jan 2003 15:55:52 -0000 1.53
--- solib.c 21 Feb 2003 20:23:43 -0000
***************
*** 160,165 ****
--- 160,169 ----
                          1, lbasename (in_pathname), O_RDONLY, 0,
                          &temp_pathname);

+   /* If not found, next use target supplied solib search method (if
existing) */
+   if (found_file < 0 && TARGET_SO_FIND_AND_OPEN_SOLIB)
+    found_file = TARGET_SO_FIND_AND_OPEN_SOLIB (in_pathname, O_RDONLY,
&temp_pathname);
+
    /* If not found, next search the inferior's $PATH environment variable.
*/
    if (found_file < 0 && solib_search_path != NULL)
      found_file = openp (get_in_environ (inferior_environ, "PATH"),
***************
*** 844,849 ****
--- 848,860 ----
    do_clear_solib (NULL);
  }

+ static void
+ reload_shared_libraries (char *ignored, int from_tty)
+ {
+   no_shared_libraries (NULL, from_tty);
+   solib_add (NULL, from_tty, NULL, auto_solib_add);
+ }
+
  void
  _initialize_solib (void)
  {
***************
*** 873,878 ****
--- 884,890 ----
  For other (relative) files, you can add values using `set
solib-search-path'.",
       &setlist);
    add_show_from_set (c, &showlist);
+   set_cmd_cfunc (c, reload_shared_libraries);
    set_cmd_completer (c, filename_completer);

    /* Set the default value of "solib-absolute-prefix" from the sysroot, if
***************
*** 885,889 ****
--- 897,902 ----
  This takes precedence over the environment variables PATH and
LD_LIBRARY_PATH.",
       &setlist);
    add_show_from_set (c, &showlist);
+   set_cmd_cfunc (c, reload_shared_libraries);
    set_cmd_completer (c, filename_completer);
  }
Index: solist.h
===================================================================
RCS file: /cvs/src/src/gdb/solist.h,v
retrieving revision 1.7
diff -c -r1.7 solist.h
*** solist.h 21 Oct 2001 19:20:30 -0000 1.7
--- solist.h 21 Feb 2003 20:23:44 -0000
***************
*** 99,104 ****
--- 99,109 ----
      /* Determine if PC lies in the dynamic symbol resolution code of
         the run time loader */
      int (*in_dynsym_resolve_code) (CORE_ADDR pc);
+
+     /* Extra hook for finding and opening a solib.  Convenience function
+        for remote debuggers finding host libs */
+     int (*find_and_open_solib) (char *soname, unsigned o_flags, char
**temp_pathname);
+
    };

  void free_so (struct so_list *so);
***************
*** 122,126 ****
--- 127,133 ----
    (current_target_so_ops->open_symbol_file_object)
  #define TARGET_SO_IN_DYNSYM_RESOLVE_CODE \
    (current_target_so_ops->in_dynsym_resolve_code)
+ #define TARGET_SO_FIND_AND_OPEN_SOLIB \
+   (current_target_so_ops->find_and_open_solib)

  #endif

Re: [Proposal] GDB honouring RPATH in binaries.

[Kevin Buettner]

Kris,

Do you have a GDB copyright assignment in place yet with the FSF?

Kevin

Re: [Proposal] GDB honouring RPATH in binaries.

[Kris Warkentin]

Yes.  We filed it when we put our binutils patch in a while back.  All I
need to do from our lawyers point of view is say, "I'm submitting this patch
on behalf of QNX Software Systems Ltd.".

BTW, wrt that last patch, I accidently included your patch for the solib
reload that you had put in the other day.  I hadn't updated my sources yet.

cheers,

Kris


----- Original Message -----
From: "Kevin Buettner" <kevinb@redhat.com>
To: "Kris Warkentin" <kewarken@qnx.com>; "Paul Koning"
<pkoning@equallogic.com>
Cc: "Colin Burgess" <cburgess@qnx.com>; <gdb@sources.redhat.com>; "Andrew
Cagney" <ac131313@redhat.com>
Sent: Friday, February 21, 2003 4:02 PM
Subject: Re: [Proposal] GDB honouring RPATH in binaries.


> Kris,
>
> Do you have a GDB copyright assignment in place yet with the FSF?
>
> Kevin
>