public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: drow@false.org
Cc: pkoning@equallogic.com, gdb@sources.redhat.com
Subject: Re: solib search algorithm for cross-gdb
Date: Wed, 03 Aug 2005 19:15:00 -0000	[thread overview]
Message-ID: <200508031915.j73JF4Oc008117@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <20050803170618.GA12169@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 3 Aug 2005 13:06:18 -0400)

   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

  parent reply	other threads:[~2005-08-03 19:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-03 13:38 Paul Koning
2005-08-03 17:06 ` Daniel Jacobowitz
2005-08-03 18:14   ` Kris Warkentin
2005-08-03 19:15   ` Mark Kettenis [this message]
2005-08-03 19:19     ` Daniel Jacobowitz
2005-08-03 19:29     ` Paul Koning
2005-08-03 20:00       ` Kris Warkentin
2005-08-03 20:16         ` Paul Koning

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200508031915.j73JF4Oc008117@elgar.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=drow@false.org \
    --cc=gdb@sources.redhat.com \
    --cc=pkoning@equallogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).