Re: Finding ld.so dynamic loader

[Michael Snyder <msnyder@specifix.com>]

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.