This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: solib search algorithm for cross-gdb


   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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]