This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 places
where G++'s class layout still does not match the published ABI
specification.

Therefore, we will have to choose whether or not we want to change G++
to match the specification.
It is easier to do this now, than later. :-( But, we screw with all the people that want ABI stability now.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]