From: David Carlton <carlton@math.stanford.edu>
To: gdb-patches@sources.redhat.com
Cc: Eli Zaretskii <eliz@gnu.org>, Daniel Jacobowitz <drow@mvista.com>,
Michael Elizabeth Chastain <mec@shout.net>
Subject: [rfa/doc] correct info about best C++ compilers/debug formats
Date: Mon, 03 Feb 2003 18:27:00 -0000 [thread overview]
Message-ID: <ro1of5t9q3x.fsf@jackfruit.Stanford.EDU> (raw)
As noted in PR symtab/874, the information in the manual about the
best debug formats for C++ is not only incorrect but actively
harmful. Here's an attempt at a patch. So:
* Eli: Is the TeXinfo okay? What about the choice of cindex entries?
When I actually looked at the index, I found that it generated three
consecutive entries "C++ and ..." that all pointed at the same
place; I'm tempted to get rid of the C++ and GCC entry, since that's
really a special case of C++ and compilers.
* Daniel (and Michael): Is the content okay? I decided to take a
conservative approach, not promising support for compilers/debug
formats that we don't intend to work on.
* Daniel, Michael: Once this goes in, should we get rid of the DWARF 1
xfails in gdb.c++ and simply not run the C++ testsuite under DWARF
1?
I'd like to apply this to 5.3 as well as mainline, on the slim chance
that 5.3.1 might happen, because the information in the doc now really
is bad.
David Carlton
carlton@math.stanford.edu
2003-02-03 David Carlton <carlton@math.stanford.edu>
* gdb.texinfo (C plus plus expressions): Correct info about
compiler/debug formats for C++ debugging. PR symtab/874.
Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.145
diff -u -p -r1.145 gdb.texinfo
--- gdb.texinfo 1 Feb 2003 20:51:06 -0000 1.145
+++ gdb.texinfo 3 Feb 2003 18:08:27 -0000
@@ -8062,28 +8062,22 @@ and @samp{@{&"hi", &"there", &"fred"@}}
@cindex expressions in C@t{++}
@value{GDBN} expression handling can interpret most C@t{++} expressions.
-@cindex C@t{++} support, not in @sc{coff}
-@cindex @sc{coff} versus C@t{++}
-@cindex C@t{++} and object formats
-@cindex object formats and C@t{++}
-@cindex a.out and C@t{++}
-@cindex @sc{ecoff} and C@t{++}
-@cindex @sc{xcoff} and C@t{++}
+@cindex C@t{++} and debug formats
+@cindex debug formats and C@t{++}
@cindex @sc{elf}/stabs and C@t{++}
@cindex @sc{elf}/@sc{dwarf} and C@t{++}
-@c FIXME!! GDB may eventually be able to debug C++ using DWARF; check
-@c periodically whether this has happened...
+@cindex C@t{++} compilers
+@cindex C@t{++} and @value{NGCC}
+@cindex @value{NGCC} and C@t{++}
@quotation
@emph{Warning:} @value{GDBN} can only debug C@t{++} code if you use the
-proper compiler. Typically, C@t{++} debugging depends on the use of
-additional debugging information in the symbol table, and thus requires
-special support. In particular, if your compiler generates a.out, MIPS
-@sc{ecoff}, RS/6000 @sc{xcoff}, or @sc{elf} with stabs extensions to the
-symbol table, these facilities are all available. (With @sc{gnu} CC,
-you can use the @samp{-gstabs} option to request stabs debugging
-extensions explicitly.) Where the object code format is standard
-@sc{coff} or @sc{dwarf} in @sc{elf}, on the other hand, most of the C@t{++}
-support in @value{GDBN} does @emph{not} work.
+proper compiler and the proper debug format. Currently, @value{GDBN}
+works best when debugging C@t{++} code that is compiled with
+@value{NGCC} 2.95.3 or with @value{NGCC} 3.1 or newer, using the options
+@option{-gdwarf-2} or @option{-gstabs+}. DWARF 2 is preferred over
+stabs; newer versions of @value{NGCC} use DWARF 2 as the default
+whenever possible. Other compilers and/or debug formats are likely to
+work badly or not at all when using @value{GDBN} to debugg C@t{++} code.
@end quotation
@enumerate
next reply other threads:[~2003-02-03 18:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-03 18:27 David Carlton [this message]
2003-02-03 18:37 ` Daniel Jacobowitz
2003-02-03 19:23 ` Eli Zaretskii
2003-02-03 20:09 ` David Carlton
2003-02-03 20:49 ` Andrew Cagney
2003-02-04 6:14 ` Eli Zaretskii
2003-02-04 5:59 ` Eli Zaretskii
2003-02-03 19:29 David Carlton
[not found] <200302032008.h13K8M230404@duracef.shout.net>
2003-02-03 20:14 ` David Carlton
2003-02-04 6:08 ` Eli Zaretskii
2003-02-04 7:04 ` Andrew Cagney
2003-02-04 21:17 ` David Carlton
2003-02-05 5:54 ` Eli Zaretskii
2003-02-03 21:21 Michael Elizabeth Chastain
2003-02-04 6:16 ` Eli Zaretskii
2003-02-04 6:24 Michael Elizabeth Chastain
2003-02-04 8:08 ` Eli Zaretskii
2003-02-04 14:41 Michael Elizabeth Chastain
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=ro1of5t9q3x.fsf@jackfruit.Stanford.EDU \
--to=carlton@math.stanford.edu \
--cc=drow@mvista.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=mec@shout.net \
/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