This is the mail archive of the
mailing list for the GCC project.
Re: C++ ABI Issues
- From: Mike Stump <mrs at apple dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 26 Aug 2002 16:18:36 -0700
- Subject: Re: C++ ABI Issues
On Monday, August 26, 2002, at 03:16 PM, Mark Mitchell wrote:
Our testing and investigation has lead to the discovery of several
where G++'s class layout still does not match the published ABI
It is easier to do this now, than later. :-( But, we screw with all
the people that want ABI stability now.
Therefore, we will have to choose whether or not we want to change G++
to match the specification.
I have always thought we needed a version independent flag that says
exactly what bug for bug compatible ABI one wanted. -fabi=92. Any and
every change that changes the abi requires a bump in the number.
People that want to sit back at any number are free to do so, and those
that can tolerate it, can move forward. We then have the engineering
framework for these changes, a way to classify them, and avoid them,
or, seek them out. abi compatible would mean that we have to support
all numbers ever used in the last 20 years.
One is perfectly free in this scheme to march any abi issue any way
they want without repercussions, as long as they bump the number, and
as long as they maintain the old abi as they do.
Failing this, it is better to get to the right standard now, almost
without delay. Maybe we need a 3.4 to replace 3.3? I don't think we
can release the change as 3.3.1.
In the end, I say, don't sweat it, as until repositories, std lib
headers survive major revs and are actually compatible with other
compilers, we don't really have much.
With the first scheme, large distributors of systems, say
RedHat/Apple/FreeBSD could stamp in which abi they wanted with what
release, and maintain it with newer and newer compilers for years and
years. As part of the release process, we would keep a running out of
how many systems have libraries based upon which revs, and after the
actual installed base of such systems drops to near 0, we could then
remove support for that abi number based upon the fact that no code
remains that needs that compatibility. A large user on a weird abi
could register it and keep it alive just as RedHat could. We have the
users help us, by telling us when to worry and when to not sweat the
details. But even if we did all that, we still face a very hard
challenge, what to do when you move the abi without the number change.
Basically, the game is rigged such that one must loose, there is no
winning or breaking even.