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.