From: Michael Elizabeth Chastain <mec@shout.net>
To: josh@carbondesignsystems.com
Cc: gdb@sources.redhat.com
Subject: Re: gdb 5.3 issues with g++ 3.2 on RedHat 7.3 & Solaris 9.
Date: Mon, 23 Dec 2002 23:15:00 -0000 [thread overview]
Message-ID: <200212240715.gBO7FdP21492@duracef.shout.net> (raw)
Hello Josh,
I notice that you didn't list any binutils versions. Are you just
using the system binutils? If so, try building binutils 2.13.1,
and then building gcc with "--with-as" and "--with-ld" flags.
Red Hat Linux 7.3 shipped with binutils-2.11.93.0.2. I've seen gdb test
failures with binutils versions 2.11.2, 2.12, and 2.12.1 that were fixed
in binutils 2.13 and later.
Constructors have a big gotcha with gcc v3: the source code of
a constructor is compiled into 2 or 3 different versions of object code.
These versions have unique mangled names (they have to, in order for
linking to work), but they have identical source code names, which leads
to a great deal of confusion. What is likely happening is that gdb
sets the breakpoint in one version of the constructor but then the
program is executing a different version. (BTW, PR gdb/892 is the
same problem).
Do this: compile this program with "gcc -S" and look at
the generated assembly code:
// ctor.cc
class Foo
{
public:
Foo ();
};
extern "C" void my_marker_function ();
Foo::Foo ()
{
my_marker_function ();
}
You will see two assembly language functions with slightly different
names, each with a call to the distinctive "my_marker_function".
There really are two functions there and gdb has trouble with that.
(There are two functions in order to implement virtual base class
initialization properly -- they are the "in-charge" constructor and
"not-in-charge" constructor -- there is a lot of detail behind that
which needs documenting).
As far as versions go, I would go with gdb 5.3, gcc 3.2.1, and binutils
2.13.1. I would try "-gdwarf-2" first and then "-gstabs+". Note the "+"
in "-gstabs+"; the plain "-gstabs" does not support C++ very all at all.
Also, "-ggdb" is always an alias for some other format, not a format of
its own, so you can drop it from your testing.
You're already on the best released gdb (5.3) and the best compiler
(gcc 3.2.1) and the two good debug formats (-gdwarf-2 and -gstabs+), and
the binutils change is minor (mostly it improved line number records).
So configuration-wise, you are close to the best configurations already,
such as they are in December 2002. Bring on the test cases and bug
reports.
Michael C
next reply other threads:[~2002-12-24 7:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-23 23:15 Michael Elizabeth Chastain [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-12-23 14:39 Joshua D. Marantz
2002-12-23 15:26 ` Daniel Jacobowitz
2003-01-11 16:43 ` Joshua D. Marantz
2003-01-11 17:02 ` Joshua D. Marantz
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=200212240715.gBO7FdP21492@duracef.shout.net \
--to=mec@shout.net \
--cc=gdb@sources.redhat.com \
--cc=josh@carbondesignsystems.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