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
next prev 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).