Re: solib search algorithm for cross-gdb

Mark Kettenis
2005-08-03T19:15:39Z

Date: Wed, 3 Aug 2005 13:06:18 -0400
From: Daniel Jacobowitz <drow@false.org>

On Wed, Aug 03, 2005 at 09:38:18AM -0400, Paul Koning wrote:
> Currently, the shared library search in solib.c first tries to use the
> shared lib filename as given (if solib-absolute-prefix isn't set).
>
> That's exactly right for a native gdb, but it is in general the wrong
> answer for a cross-gdb. If I'm debugging a mips box, or analyzing a
> mips corefile, resolving shared lib symbols from intel shared libs in
> my /usr/lib is the wrong thing.
>
> .gdbinit helps, but not everyone remembers to do this right every
> time.
>
> I was thinking about having the case of "use the filename exactly as
> supplied" in solib.c be used only in native gdb. That seems to
> require adding stuff in configure and config.in to tell a native from
> a cross build.
>
> I could submit this patch if it sounds like a good feature (otherwise
> I'll probably keep it as a private change). Comments? Better ways to
> do this?

There's an argument that this should be based primarily on the target.
Using the native files is generally right for target "child"; generally
wrong (though not necessarily) for target "remote"; and generally right
for target "core" iff this is a native GDB.

Indeed. What's important to really that even a native gdb can be used
for cross-debugging. Therefore, it's probably a better idea to
determine "nativeness" at run time, by comparing the architecture and
OS/ABI to the system gdb is running on.

Incidentally, at least for POSIX systems, it seems that we generally
have a tree rooted somewhare. I think the architecture vector should
describe the layout of that tree for a certain OS/ABI whereas the root
of that tree would be determined by some heuristic based on the target
(child, remote, core) and nativeness. Obviously for native child and
core the root would be /. For remote we should probably default to
whatever was specified using --with-sysroot when gdb was configured.

I don't know if that's worth implementing. I'm inclined to say that
your suggestion is progress, at least.

Hmm. I get the feeling we have been tweaking things too much already
in the past. I'd really prefer someone making a well though-out
design and implementing things properly.

Mark