From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
To: cagney@gnu.org, mec.gnu@mindspring.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/testsuite/cp] local.exp: accommodate gcc abi 2
Date: Mon, 05 Jan 2004 20:27:00 -0000 [thread overview]
Message-ID: <20040105202810.13B264B35A@berman.michael-chastain.com> (raw)
ac> Is this "The New ABI" or a yet to be named but for the moment would be
ac> best refered to as "The New New ABI"?
The former.
It's minor version 2 of "The New ABI", also known as "The IA-64 ABI".
It contains small bug fixes to g++ to make it more compatible with
the spec for "The New ABI".
gcc 2.95.3 old abi
gcc 3.3.2 new abi, version 1
gcc 3.4.0 new abi, version 2
Here's an example of the differences between "new abi, version 1"
and "new abi, version 2": suppose that a class has a virtual destructor,
but the user doesn't specify the virtual destructor, so the compiler
synthesizes it. With "new abi, version 1", the synthesized virtual
destructor appears in the vtable *before* the user's own virtual
methods. With "new abi, version 2", the synthesized virtual destructor
appears in the vtable *after* the user's own virtual methods.
There are about 5-10 tweaks like this in gcc 3.4.
So it's not "New New ABI", fortunately for us. It's just bug fixes
to "New ABI". It's the same mangling scheme and same data structures,
but gcc puts slightly different data into them. Different enough that
g++ 3.3.X and g++ 3.4.X are sometimes not link-compatible, but similar
enough that gdb will not need a new module.
gcc 3.4 has a flag "-fabi-version" to select between "New Abi,
version 1" and "New Abi, version 2". "New Abi, version 2" is the
default.
Michael C
next reply other threads:[~2004-01-05 20:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-05 20:27 Michael Elizabeth Chastain [this message]
2004-01-05 21:34 ` Andrew Cagney
-- strict thread matches above, loose matches on Subject: below --
2004-01-03 1:45 Michael Elizabeth Chastain
2004-01-05 16:01 ` Andrew Cagney
2004-01-05 16:05 ` Daniel Jacobowitz
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=20040105202810.13B264B35A@berman.michael-chastain.com \
--to=mec.gnu@mindspring.com \
--cc=cagney@gnu.org \
--cc=gdb-patches@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