From: Michael Chastain <mec.gnu@mindspring.com>
To: eliz@gnu.org, ddaney@avtrex.com, cagney@gnu.org
Cc: gdb@sources.redhat.com
Subject: Re: Unable to step over (n and ni) on mipsel-linux...
Date: Mon, 23 Aug 2004 19:05:00 -0000 [thread overview]
Message-ID: <412A3FF4.nailCRF28XFLA@mindspring.com> (raw)
In-Reply-To: <412A30E5.9080809@avtrex.com>
David Daney <ddaney@avtrex.com> wrote:
> By compiler dependant, do you mean the compiler GDB was built with, or
> the one that compiled the target code?
This question comes up a lot -- I think it's underdocumented,
so I'll take a TODO item to write some more documentation on it.
Here's a brain dump. David, you know half this stuff already,
I'm just collecting it into one place.
===
The version of GDB is important.
The compiler that GDB was built with is important if:
. gdb fails to build
. a test in gdb.gdb/*.exp is the issue
If gdb builds successfully, and you're not running one of the tests in
gdb.gdb (which tests the gdb executable itself), then the compiler that
built GDB usually does not influence GDB's behavior at run-time.
GDB is just a big C program. If a C compiler can compile GDB, it usually
compiles it the way we meant it to.
The target architecture is always important.
The target operating system is always important.
The host architecture and the host operating system are of secondary
importance. They might be important if the issue involves the remote
protocol and the host operating system is unusually weird.
The compiler that built the target code is critical! The target
compiler is the program that writes all the debugging information which
GDB reads. We nearly always need the name and version of the compiler
that built the target code.
Obviously, the debug flags (-g or -ggdb or -gdwarf-2 or -gstabs+)
are critical too.
Usually the target assembler and target linker are not important,
because the target compiler generates the debugging information and
the target assembler and target linker just pass them through.
GDB is sometimes sensitive to the target linker for issues with
shared libraries.
The target's standard C library is important if the problem involves
threads or the problem involves backtracing through the standard library.
next prev parent reply other threads:[~2004-08-23 19:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-20 19:02 David Daney
2004-08-20 19:20 ` Theodore A. Roth
2004-08-23 17:14 ` Andrew Cagney
2004-08-23 18:04 ` David Daney
2004-08-23 18:26 ` Andrew Cagney
2004-08-23 18:42 ` David Daney
2004-08-23 18:48 ` Daniel Jacobowitz
2004-08-23 19:01 ` David Daney
2004-08-23 19:22 ` Daniel Jacobowitz
2004-08-24 19:29 ` Andrew Cagney
2004-08-23 19:05 ` Michael Chastain [this message]
2004-08-23 19:19 ` David Daney
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=412A3FF4.nailCRF28XFLA@mindspring.com \
--to=mec.gnu@mindspring.com \
--cc=cagney@gnu.org \
--cc=ddaney@avtrex.com \
--cc=eliz@gnu.org \
--cc=gdb@sources.redhat.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