C++ ABI Issues

[Jeff Law]

In message < 20020827082658.A7917@sunsite.ms.mff.cuni.cz >, Jakub Jelinek writes:
 >On Mon, Aug 26, 2002 at 05:10:19PM -0700, Joe Buck wrote:
 >> A more controversial possibility is to add an *option* to correct the
 >> ABI bugs in 3.2.1, but make 3.2 compatibility the default.  I'm less
 >> sure whether this is the right approach; we should first try to determine
 >> how pervasive this problem is.  One possibility: do the ABI-warning patch,
 >> ask our friends at Red Hat, Debian, and FreeBSD to build their whole
 >> distributions+ports with it and see how many warnings we get.  If it
 >
 >This is what we at Red Hat are about to do today.
And I think this needs to become standard operating procedure when we
encounter ABI changes.  ie, we update both the current release branch
and the mainline sources to detect and optionally warn/error about the ABI
change.  In fact, we should track ABI changes with some kind of tracking
number (see below).

One of the big issues going forward is that we be able to run code 
through the compiler and have the compiler tell us if that code triggers
an ABI bug.

What would be even better would be ways to annotate objects with this
kind of information.  It wouldn't be perfect, but the ability to add a
note section which could tell us a few things:

  1. What version of the compiler was used to compile the object
     (which implicitly gives us the ABI, though we may want to make
     the ABI revision explicit).

  2. Record what (if any) ABI bugs this file is known to tickle.


With some work we could even have the linker and dynamic loader issue
errors/warnings when mixing/matching code from different ABIs with known
issues.

Clearly this isn't perfect as it's impossible to annotate an object with
"violates bug X" until after bug X is found.  But I still think it would
be extremely helpful going forward.  Further revisions on the scheme would
be greatly appreciated.

 >
 >Personally, I think there is no point to make 3.3 ABI incompatible
 >with 3.2 without extensive ABI testsuite in place (and I don't think it
 >is manageable to come up with one in 3.3 timeframe unless it is delayed),
 >otherwise we're back where G++ used to be - every single version is ABI
 >incompatible with all the others. The chances some ABI problem will come
 >up in the next half a year is simply too high without testsuite.
 >So IMHO the ABI changes could wait for 3.4 together with ABI testsuite.
Agreed.  Let's get the ABI/API testsuite into a state where we have a good
amount of confidence that it's testing all the things we care about before
we twiddle the ABI again.  Otherwise we've really not made any significant
progress for our end-users on the "every major release of the compiler is
incompatible with every other major release" problem.

jeff