This is the mail archive of the
mailing list for the GCC project.
Re: C++ ABI Issues
- From: Joe Buck <Joe dot Buck at synopsys dot com>
- To: mark at codesourcery dot com (Mark Mitchell)
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 26 Aug 2002 17:10:19 -0700 (PDT)
- Subject: Re: C++ ABI Issues
> Our testing and investigation has lead to the discovery of several places
> where G++'s class layout still does not match the published ABI
> specification. ...
> Here are the issues:
> 1. Tail-padding of bit-fields
> 2. Tail-padding and virtual base classes
> My expectation is that case 1 is relatively uncommon, but that case 2 is
> relatively common.
Question: does anyone know if case 2 affects anything in libstdc++?
(e.g. iostream classes?)
I would be against jumping quickly to a 3.3 that fixes these; we still
won't know if we have caught all of the problems. These things usually
follow an exponential curve (that is, the rate of finding new bugs in a
given area that you aren't actively changing decays exponentially with
time), so if you've already found two errors in only a week, we probably
aren't done yet. My wild guess (based just on intuition) is that we'll
find a third within two months, at least.
I recommend instead that, for 3.2.1, we add code to issue a warning when
one of the above situations occur. We might even want to make the patch
to generate such warnings more prominently available, so that if people
suspect a problem they can check for it now. Then people who want to
write code that won't be affected by the bug can add explicit padding
as needed to eliminate the tail-padding slot that some vendors would
Old-time GCC users may remember that for years GCC used a different
convention by default to return structs on some OSes, and people dealt
with that by adding a warning that would flag the returning of structs.
The concept was to allow programmers to avoid the areas where
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
happens a lot, we have something to think about.
> I propose that we fix G++ to match the ABI, but that we issue warnings
> about classes whose layout has changed from GCC 3.2.
I want to see the warnings ASAP, but I'm concerned about the disruption of
another ABI change when we can't be sure that it will be the last one.
Finally, there's the issue of how far we bend over to make it easier to
accomodate the proprietary competition to GCC on GNU/Linux. That is, who
are we doing this ABI for? Describing GCC so precisely so that it can be
easily replaced? Mind you, I *do* want good documentation and adherence
to standards, and I'm against the introduction of any artificial barriers,
but the distributors really, really wanted a release that would re-unify
the world and we gave it to them. Maybe the best thing in the short term
is for the competition to release patches to make their compilers
bug-compatible with GCC.
As you say, there was plenty of warnings that we might not have caught