Finding ld.so dynamic loader

Finding ld.so dynamic loader

[Michael Eager]

I've been reading through solib_open() in solib.c and the way
that the code searches for the dynamic loader doesn't make sense
to me, especially when using gdbserver to debug a program on
a remote system.  Perhaps someone can explain to me why it is correct.

solib_open() is called by enable_break() with the name of
the dynamic loader, say, "/lib/ld.so.1".  The comments at
the top of solib_open() say:

  125    * If there is a solib_absolute_prefix and path is absolute:
  126    *   Search for solib_absolute_prefix/path.
  127    * else
  128    *   Look for it literally (unmodified).
  129    * Look in SOLIB_SEARCH_PATH.
  130    * If available, use target defined search function.
  131    * If solib_absolute_prefix is NOT set, perform the following two searches:
  132    *   Look in inferior's $PATH.
  133    *   Look in inferior's $LD_LIBRARY_PATH.

If solib_absolute_prefix is empty (true for almost all targets) and
/lib/ld.so.1 exists on the host system, this will be opened in
preference to either one specified on the SOLIB_SEARCH_PATH or using a
target search path.

This seems incorrect.  The dynamic loader on the host system
may not be the same as on the target system, and in the case
of cross development, may not even have the same architecture.
Shouldn't the search using the unmodified name be the last choice,
not the first?

Can someone explain to me how gdb is supposed to find the correct
ld.so or why I'm looking at this incorrectly?

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Finding ld.so dynamic loader

[Daniel Jacobowitz]

On Wed, Jan 30, 2008 at 08:42:00AM -0800, Michael Eager wrote:
> If solib_absolute_prefix is empty (true for almost all targets) and
> /lib/ld.so.1 exists on the host system, this will be opened in
> preference to either one specified on the SOLIB_SEARCH_PATH or using a
> target search path.

In my opinion, there's the mistake: solib_absolute_prefix isn't
related to your target.  It's a configuration setting, and if you're
using gdbserver to talk to a remote system, you should set it ("set
sysroot").  If you don't have the same layout as your target
reproduced on your host, set it to a nonexistant path.

That said, I'm not sure why we search the literal path before the
search path either.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Finding ld.so dynamic loader

[Michael Eager]

Daniel Jacobowitz wrote:
> On Wed, Jan 30, 2008 at 08:42:00AM -0800, Michael Eager wrote:
>> If solib_absolute_prefix is empty (true for almost all targets) and
>> /lib/ld.so.1 exists on the host system, this will be opened in
>> preference to either one specified on the SOLIB_SEARCH_PATH or using a
>> target search path.
> 
> In my opinion, there's the mistake: solib_absolute_prefix isn't
> related to your target.  It's a configuration setting, and if you're
> using gdbserver to talk to a remote system, you should set it ("set
> sysroot").  If you don't have the same layout as your target
> reproduced on your host, set it to a nonexistant path.
> 
> That said, I'm not sure why we search the literal path before the
> search path either.

Apparently, there is some error in parsing "set sysroot":

   (gdb) set sysroot /tmp
   No symbol "sysroot" in current context.

"set solib-absolute-prefix" does set the prefix.

IMO, if this prefix is not set by the user, the environment
symbol or path should be searched, with the host system searched
as a final choice.  I can create a patch to do this if desired.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Finding ld.so dynamic loader

[Daniel Jacobowitz]

On Wed, Jan 30, 2008 at 09:00:35AM -0800, Michael Eager wrote:
> Apparently, there is some error in parsing "set sysroot":
>
>   (gdb) set sysroot /tmp
>   No symbol "sysroot" in current context.

I suspect your version of GDB predates the "set sysroot" name;
solib-absolute-prefix is a lot older.

> IMO, if this prefix is not set by the user, the environment
> symbol or path should be searched, with the host system searched
> as a final choice.  I can create a patch to do this if desired.

It's harder than it sounds to figure out whether we're native
debugging or remote debugging once you're down in the shared library
code; I don't think it's worth it.  I have no preference whether we
search the solib-search-path before or after the sysroot, though I am
a little worried about breaking existing setups...

-- 
Daniel Jacobowitz
CodeSourcery

Re: Finding ld.so dynamic loader

[Michael Eager]

Daniel Jacobowitz wrote:
> On Wed, Jan 30, 2008 at 09:00:35AM -0800, Michael Eager wrote:
>> IMO, if this prefix is not set by the user, the environment
>> symbol or path should be searched, with the host system searched
>> as a final choice.  I can create a patch to do this if desired.
> 
> It's harder than it sounds to figure out whether we're native
> debugging or remote debugging once you're down in the shared library
> code; I don't think it's worth it.  I have no preference whether we
> search the solib-search-path before or after the sysroot, though I am
> a little worried about breaking existing setups...

There's a chain of calls from remote_open() to enable_break()
to solib_open().  It would be possible to set a global flag
(arrgh!) in remote_open() which could be checked in solib_open().
It would also seem reasonable to have a flag set in the gdb-arch
code to say not to search host system directories.

Somewhere along the way the principle of least surprise should
kick in.  I only noticed this because my target has a dynamic
loader named "/lib/ld.so.1".  If it had been "/lib/ld-linux.so.2"
then gdb would have quietly placed a breakpoint on the target
at whatever location would be correct on the host system.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Finding ld.so dynamic loader

[Michael Eager]

It seems that as soon as I ask a question, the answer drops into
my lap.  There's a "set solib-absolute-prefix" command which
sets the prefix to use to find the shared libraries.

Michael Eager wrote:
> I've been reading through solib_open() in solib.c and the way
> that the code searches for the dynamic loader doesn't make sense
> to me, especially when using gdbserver to debug a program on
> a remote system.  Perhaps someone can explain to me why it is correct.
> 
> solib_open() is called by enable_break() with the name of
> the dynamic loader, say, "/lib/ld.so.1".  The comments at
> the top of solib_open() say:
> 
>  125    * If there is a solib_absolute_prefix and path is absolute:
>  126    *   Search for solib_absolute_prefix/path.
>  127    * else
>  128    *   Look for it literally (unmodified).
>  129    * Look in SOLIB_SEARCH_PATH.
>  130    * If available, use target defined search function.
>  131    * If solib_absolute_prefix is NOT set, perform the following two 
> searches:
>  132    *   Look in inferior's $PATH.
>  133    *   Look in inferior's $LD_LIBRARY_PATH.
> 
> If solib_absolute_prefix is empty (true for almost all targets) and
> /lib/ld.so.1 exists on the host system, this will be opened in
> preference to either one specified on the SOLIB_SEARCH_PATH or using a
> target search path.
> 
> This seems incorrect.  The dynamic loader on the host system
> may not be the same as on the target system, and in the case
> of cross development, may not even have the same architecture.
> Shouldn't the search using the unmodified name be the last choice,
> not the first?
> 
> Can someone explain to me how gdb is supposed to find the correct
> ld.so or why I'm looking at this incorrectly?
> 


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Finding ld.so dynamic loader

[Mark Kettenis]

> Date: Wed, 30 Jan 2008 08:42:00 -0800
> From: Michael Eager <eager@eagercon.com>
> 
> I've been reading through solib_open() in solib.c and the way
> that the code searches for the dynamic loader doesn't make sense
> to me, especially when using gdbserver to debug a program on
> a remote system.  Perhaps someone can explain to me why it is correct.
> 
> solib_open() is called by enable_break() with the name of
> the dynamic loader, say, "/lib/ld.so.1".  The comments at
> the top of solib_open() say:
> 
>   125    * If there is a solib_absolute_prefix and path is absolute:
>   126    *   Search for solib_absolute_prefix/path.
>   127    * else
>   128    *   Look for it literally (unmodified).
>   129    * Look in SOLIB_SEARCH_PATH.
>   130    * If available, use target defined search function.
>   131    * If solib_absolute_prefix is NOT set, perform the following two searches:
>   132    *   Look in inferior's $PATH.
>   133    *   Look in inferior's $LD_LIBRARY_PATH.
> 
> If solib_absolute_prefix is empty (true for almost all targets) and
> /lib/ld.so.1 exists on the host system, this will be opened in
> preference to either one specified on the SOLIB_SEARCH_PATH or using a
> target search path.
> 
> This seems incorrect.  The dynamic loader on the host system
> may not be the same as on the target system, and in the case
> of cross development, may not even have the same architecture.
> Shouldn't the search using the unmodified name be the last choice,
> not the first?
> 
> Can someone explain to me how gdb is supposed to find the correct
> ld.so or why I'm looking at this incorrectly?

Oh that's an easy one.  GDB got corrupted by the embedded crowd who
can't settle on a single way to build and install a cross toolchain.
GDB tries to please them all, and still tries to cover the case of a
native debugger too.

Oh, by the way, you're looking at an old GDB version; we also have
GDB_SYSROOT now.

Re: Finding ld.so dynamic loader

[Michael Eager]

Mark Kettenis wrote:

>> Can someone explain to me how gdb is supposed to find the correct
>> ld.so or why I'm looking at this incorrectly?
> 
> Oh that's an easy one.  GDB got corrupted by the embedded crowd who
> can't settle on a single way to build and install a cross toolchain.

I'll plead nolo contendere.  All the variations in building a cross
toolchain are as confusing to toolchain developers as debugger developers.

> GDB tries to please them all, and still tries to cover the case of a
> native debugger too.

It still seems that searching the host file system should be the
last choice, not the first.  This makes setting the solib search path or
using a target-dependent search function moot, unless the user also
sets the solib search prefix to a bogus value.

> Oh, by the way, you're looking at an old GDB version; we also have
> GDB_SYSROOT now.

Yes, I'm using gdb-6.5.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Finding ld.so dynamic loader

[Paul Koning]

>>>>> "Michael" == Michael Eager <eager@eagercon.com> writes:

 Michael> Mark Kettenis wrote:
 >> GDB tries to please them all, and still tries to cover the case of
 >> a native debugger too.

 Michael> It still seems that searching the host file system should be
 Michael> the last choice, not the first. 

It should either be the last choice, or not be done at all.  An
example where it should not be done at all is when host and target are
different architectures.  Looking up a symbol in an x86 library when
you're debugging a MIPS target cannot ever be correct -- but that's
what can happen today.  (This is also an example of something that can
easily be checked by the solib code without worrying about the
"remote" vs. "local" distinction -- if host != target then by
definition the host libraries are wrong.)

     paul

Re: Finding ld.so dynamic loader

[Michael Eager]

Paul Koning wrote:
>>>>>> "Michael" == Michael Eager <eager@eagercon.com> writes:
> 
>  Michael> Mark Kettenis wrote:
>  >> GDB tries to please them all, and still tries to cover the case of
>  >> a native debugger too.
> 
>  Michael> It still seems that searching the host file system should be
>  Michael> the last choice, not the first. 
> 
> It should either be the last choice, or not be done at all.  An
> example where it should not be done at all is when host and target are
> different architectures.  Looking up a symbol in an x86 library when
> you're debugging a MIPS target cannot ever be correct -- but that's
> what can happen today.  (This is also an example of something that can
> easily be checked by the solib code without worrying about the
> "remote" vs. "local" distinction -- if host != target then by
> definition the host libraries are wrong.)

It's certainly incorrect to look up a symbol when the host
and target architectures are different.  But it's also
incorrect when the architectures are the same but the library
versions are different.  For example, debugging a x86 Linux 2.4
target with an x86 Linux 2.6 host.  I'd rather see a fix which
handles both situations.

Essentially, any time gdb is working with a remote target,
searching the host file system should be suppressed.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Finding ld.so dynamic loader

[Mark Kettenis]

> Date: Wed, 30 Jan 2008 13:05:38 -0800
> From: Michael Eager <eager@eagercon.com>
> 
> Paul Koning wrote:
> >>>>>> "Michael" == Michael Eager <eager@eagercon.com> writes:
> > 
> >  Michael> Mark Kettenis wrote:
> >  >> GDB tries to please them all, and still tries to cover the case of
> >  >> a native debugger too.
> > 
> >  Michael> It still seems that searching the host file system should be
> >  Michael> the last choice, not the first. 
> > 
> > It should either be the last choice, or not be done at all.  An
> > example where it should not be done at all is when host and target are
> > different architectures.  Looking up a symbol in an x86 library when
> > you're debugging a MIPS target cannot ever be correct -- but that's
> > what can happen today.  (This is also an example of something that can
> > easily be checked by the solib code without worrying about the
> > "remote" vs. "local" distinction -- if host != target then by
> > definition the host libraries are wrong.)
> 
> It's certainly incorrect to look up a symbol when the host
> and target architectures are different.  But it's also
> incorrect when the architectures are the same but the library
> versions are different.  For example, debugging a x86 Linux 2.4
> target with an x86 Linux 2.6 host.  I'd rather see a fix which
> handles both situations.

Bad example; Linux kernel versions have very little to do with this
and if both systems use the same userland things would work fine.

> Essentially, any time gdb is working with a remote target,
> searching the host file system should be suppressed.

I'm not sure everybody would agree with you here, although one could
argue that if people would want to search the host filesystem in this
case, they can always set solib-absolute-prefix and/or
solib-search-path.

Re: Finding ld.so dynamic loader

[Michael Snyder]

On Wed, 2008-01-30 at 13:05 -0800, Michael Eager wrote:
> Paul Koning wrote:
> >>>>>> "Michael" == Michael Eager <eager@eagercon.com> writes:
> > 
> >  Michael> Mark Kettenis wrote:
> >  >> GDB tries to please them all, and still tries to cover the case of
> >  >> a native debugger too.
> > 
> >  Michael> It still seems that searching the host file system should be
> >  Michael> the last choice, not the first. 
> > 
> > It should either be the last choice, or not be done at all.  An
> > example where it should not be done at all is when host and target are
> > different architectures.  Looking up a symbol in an x86 library when
> > you're debugging a MIPS target cannot ever be correct -- but that's
> > what can happen today.  (This is also an example of something that can
> > easily be checked by the solib code without worrying about the
> > "remote" vs. "local" distinction -- if host != target then by
> > definition the host libraries are wrong.)
> 
> It's certainly incorrect to look up a symbol when the host
> and target architectures are different.  But it's also
> incorrect when the architectures are the same but the library
> versions are different.  For example, debugging a x86 Linux 2.4
> target with an x86 Linux 2.6 host.  I'd rather see a fix which
> handles both situations.

Yeah, but gdb already has knowledge about architectures.
It doesn't have any knowledge about library versions.

> Essentially, any time gdb is working with a remote target,
> searching the host file system should be suppressed.

In the testsuites, we have a method called something like
"is_remote_target".  Perhaps if it's useful there, it would
be useful internally in gdb as well?

As Daniel said, presently it can be pretty arcane to figure out.