3.1/3.2 C++ ABI change

3.1/3.2 C++ ABI change

[Matt Austern]

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

Re: 3.1/3.2 C++ ABI change

[David Edelsohn]

>>>>> Matt Austern writes:

Matt> (1) Was it the intention behind the ABI compatibility switch that it
Matt> should cover this vtable change?

	The ABI compatibility switch is suppose to allow a choice among
multiple ABI changes.  The current choices are 3.2 or current.  GCC 3.1
was declared no longer supported.  If you want to add another option to
the switch to handle GCC 3.1, it is up to the maintainer to decide whether
to accept and support that into the future.

	Theoretically the "switch" can handle the vtable change, but the
current implementation does not have an option for GCC 3.1 compatibility.

David

Re: 3.1/3.2 C++ ABI change

[Mark Mitchell]

> (If I'm wrong on the above, and if this vtable change is just a bug,
> please correct me.)

You're correct.

> So,...
> (1) Was it the intention behind the ABI compatibility switch that it
> should cover this vtable change?

No.

The point of 3.2 was to provide a stable point from which we would try
to maintain compatibility for a long period of time.  Bugs that we have
found after that point are under control of the ABI switch.  Nobody
has a clear plan for when (or if) that new mode will become the default;
note, however, that the 3.2 ABI has known bugs, not with respect to the
ABI, but with respect to the language.  (For example, there are ways to
get two objects of the same type at the same address.)

> (2) If Apple provided code allowing C++ ABI compatibility with 3.1,
> would people be interested?

I don't know.

Personally, I think it's tempting to add these switches, but
next-to-impossible to implement them.  Something will change at some
point, without anyone meaning to change it; I think these switches
tend to offer a false hope.  And everyone making changes going forward
has to understand all of the ABIs and all of the weird code we're
keeping around that is wrong, but was used in one of the old ABIs.

I am hoping that we will not switch the default from the 3.2 ABI until
we are more confident we've got the new ABI right; to me, that means at
least passing our testsuite.  (G++ is doing pretty well on the layout
stuff that we have now, but we have not completed the rest of the work.)

So, *I* am not interested -- but I would not launch a concerted
campaign to stop you. :-)

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com