Re: Finding ld.so dynamic loader

Michael Snyder
2008-01-31T11:27:24Z

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.