This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
3.1/3.2 C++ ABI change
- From: Matt Austern <austern at apple dot com>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 7 Oct 2002 14:07:45 -0700
- Subject: 3.1/3.2 C++ ABI change
Consider the following snippet:
struct VBase {
int n1;
virtual ~VBase();
virtual void f();
};
struct Derived : public virtual VBase {
int n2;
virtual ~Derived();
virtual void g();
};
VBase::~VBase() { }
Derived::~Derived() { }
With gcc 3.1, the beginning of Derived's vtable is:
_ZTV7Derived:
.long 8
.long 0
.long _ZTI7Derived
.long _ZN7Derived1gEv
.long _ZN7DerivedD1Ev
.long _ZN7DerivedD0Ev
.long 0
.long -8
.long -8
...
With 3.2, on the other hand, these entries are:
_ZTV7Derived:
.long 8
.long 0
.long _ZTI7Derived
.long _ZN7DerivedD1Ev
.long _ZN7DerivedD0Ev
.long _ZN7Derived1gEv
.long 0
.long -8
.long -8
...
My understanding is that this was an intentional change, because the
implementation of the ABI was incorrect in 3.1. My understanding, in
fact, is that this was the whole point of the 3.2 release: there are
very
few differences between 3.1 and 3.2 other than this ABI-breaking
change. System vendors were encouraged to ship 3.2, which was
hoped to have a more stable C++ ABI. Correct so far?
(If I'm wrong on the above, and if this vtable change is just a bug,
please correct me.)
The problem, of course, is that Apple shipped 3.1 as our system
compiler. We're trying to figure out what to do next. It looks like
there's some machinery in the compiler that lets users ask for
ABI compatibility with earlier compiler versions. It also looks like
it's incomplete, and that it doesn't cover this particular vtable layout
change.
So,...
(1) Was it the intention behind the ABI compatibility switch that it
should cover this vtable change?
(2) If Apple provided code allowing C++ ABI compatibility with 3.1,
would people be interested?
--Matt