GCC's ABI 5

[Renato Golin]

Folks,

I'd like to know the general opinion on this:

https://llvm.org/bugs/show_bug.cgi?id=23529

From past experience, and my limited point of view, it seems that the
GCC community decided to change the ABI, plotted some runes, conjured
up a broken implementation (whose bugs people will exploit and GCC
will end up keeping them) and pushed distros to follow.

I don't know how much distros were involved in the original design.
Did they request the changes? Or was that an internal change? How do
you guys get to decide when to break the world?

I also don't know how will be your policy towards the bugs that people
started "using". Are you going to force them moving to a more sane
implementation (by issuing compiler/linker errors) or are you going to
support as legacy for the decades to come?

Is there a detailed document describing all the changes, and is the
GCC implementation following that to the letter, or are there still
bugs in the current version? I'm not talking about an email thread,
but an actual document on GCC's docs pages.

All I know is that people in the Clang community waited until GCC's
implementation was stable, but somehow Debian based distros started
moving as if there was something unholy about the previous ABI, and
we've been getting segmentation faults on Hello World!

I don't know much about the changes myself, nor I was involved in the
discussion, but this is now a major pain for release 3.8.0 and I
thought it would be better if I sent an email to Linaro folks and
members (which form most of the ARM GNU developers) instead of going
on the main lists.

That also gives me a bit more freedom to be more candid. I wouldn't
send those questions as they are to the GCC/binutils lists, or people
would kill me. I don't mean any of them as an offence, they are
genuine questions from someone that is not on top of that issue.

cheers,
--renato

[Yvan Roux]

Hi Renato,

Post by Renato Golin
Folks,
https://llvm.org/bugs/show_bug.cgi?id=23529
From past experience, and my limited point of view, it seems that the
GCC community decided to change the ABI, plotted some runes, conjured
up a broken implementation (whose bugs people will exploit and GCC
will end up keeping them) and pushed distros to follow.
I don't know how much distros were involved in the original design.
Did they request the changes? Or was that an internal change? How do
you guys get to decide when to break the world?
I also don't know how will be your policy towards the bugs that people
started "using". Are you going to force them moving to a more sane
implementation (by issuing compiler/linker errors) or are you going to
support as legacy for the decades to come?
Is there a detailed document describing all the changes, and is the
GCC implementation following that to the letter, or are there still
bugs in the current version? I'm not talking about an email thread,
but an actual document on GCC's docs pages.
All I know is that people in the Clang community waited until GCC's
implementation was stable, but somehow Debian based distros started
moving as if there was something unholy about the previous ABI, and
we've been getting segmentation faults on Hello World!
I don't know much about the changes myself, nor I was involved in the
discussion, but this is now a major pain for release 3.8.0 and I
thought it would be better if I sent an email to Linaro folks and
members (which form most of the ARM GNU developers) instead of going
on the main lists.
That also gives me a bit more freedom to be more candid. I wouldn't
send those questions as they are to the GCC/binutils lists, or people
would kill me. I don't mean any of them as an offence, they are
genuine questions from someone that is not on top of that issue.

I don't know well the abi_tag story, and will have to dig in the
discussions to give you an answer, but you might find some answers in
Jason's blog:

http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/

Cheers,
Yvan

Post by Renato Golin
cheers,
--renato
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Jim Wilson]

Post by Renato Golin
I don't know how much distros were involved in the original design.
Did they request the changes? Or was that an internal change? How do
you guys get to decide when to break the world?

It appears that changes to the C++ standard forced the ABI change, and
the addition of abi_tag was an attempt to support both C++ standard
versions in parallel during the transition period.

I see a patch from Jason Merrill here
https://gcc.gnu.org/ml/gcc-patches/2012-11/msg00475.html
which says this was discussed at the GNU Cauldron in Prague in 2012.
I was there, but I 'm not a C++ guy, so I don't recall this
discussion. The GNU Cauldron is well attended by various distro
contributors (Debian/Ubuntu, Red Hat, SuSE at least), so there should
have been reasonable coverage at the time. I don't know if any clang
representatives were present.

It appears that a complaint from doko started this mess. I see two
parallel threads complaining about ABI incompatibilities between C++98
and C++11 right before the GNU Cauldron, one of which is from doko.
https://gcc.gnu.org/ml/gcc/2012-06/msg00201.html
https://gcc.gnu.org/ml/gcc/2012-06/msg00202.html

Then in July, I see a third thread started by Jason Merrill that seems
to have the first suggestion of using an attribute to change mangling.
https://gcc.gnu.org/ml/gcc/2012-07/msg00031.html

Then during the Cauldron, a summary of the C++ ABI BOF which I likely
did not attend
https://gcc.gnu.org/ml/gcc/2012-07/msg00098.html
See in particular Ian's reply which has a lot more details about the
proposed GNU solution. The initial message mentions HP and Sun
solutions to this problem, but doesn't talk much about the GNU
solution. This talk would have been attended by Ubuntu, Red Hat, and
SuSE folks at least, so there should have been some agreement from the
distros before we implemented a solution.

Then eventually came Jason's initial implementation patch in November.

While the feature was added a while ago, it wasn't until C++11 was
made the default that it became visible to end users, and that
happened with GCC 5. Maybe there wasn't enough discussion with the
clang guys before the switch was made from C++98 to C++11. Us gcc
guys aren't used to having to discuss things with other compiler
developers. We are good about talking to distro vendors, but we keep
forgetting about clang.

I found an old wiki page that talks about ABI changes between C++98 and C++11.
https://gcc.gnu.org/wiki/Cxx11AbiCompatibility

I doubt that there is any formal specification of any of this stuff
anywhere. The attribute abi_tag is documented in the gcc manual.
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes
You perhaps care more about how libstdc++ uses it, which isn't in the
gcc manual. I do see two mentions in the libstdc++ docs
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
https://gcc.gnu.org/onlinedocs/libstdc++/manual/api.html

Most of the discussion of this feature probably occurred on the
libstdc++ mailing list which I don't read. I have limited knowledge
of C++, and basically no knowledge of the gcc C++ front end, so I
can't comment on the C++ technical matters here.

Jim

[Renato Golin]

Hi Jim,

Thanks for your in-depth response!

If I got it right, the C++11 standard didn't mandate a new ABI, but
libstdc++'s ABI would break in the new standard. Our own libc++ was
created with C++11 in mind, so we required no alterations or ABI
changes.

Post by Jim Wilson
It appears that a complaint from doko started this mess.

As usual... :)

Post by Jim Wilson
Then in July, I see a third thread started by Jason Merrill that seems
to have the first suggestion of using an attribute to change mangling.
https://gcc.gnu.org/ml/gcc/2012-07/msg00031.html

Hum, it's not just mangling, they also changed the object layout. Now
it starts to make sense.

The problem we see is with segfaults when compiling "Hello World"
using iostream, but a mangling-only problem would manifest at compile
time. Changing the representation of std:: objects will, most
definitely, screw up things badly.

Post by Jim Wilson
While the feature was added a while ago, it wasn't until C++11 was
made the default that it became visible to end users, and that
happened with GCC 5. Maybe there wasn't enough discussion with the
clang guys before the switch was made from C++98 to C++11. Us gcc
guys aren't used to having to discuss things with other compiler
developers. We are good about talking to distro vendors, but we keep
forgetting about clang.

Clang folks aren't good either, but this is exactly the kind of big
deal that affects everyone I mentioned in my talk at the Cambridge
cauldron (2014).

Mangling can easily be caught and fixed, but object layout is a major
pain in the ass, *especially* when it's not documented, nor stable.

Post by Jim Wilson
I found an old wiki page that talks about ABI changes between C++98 and C++11.
https://gcc.gnu.org/wiki/Cxx11AbiCompatibility

That's a good start, but I doubt it covers everything.

Post by Jim Wilson
I doubt that there is any formal specification of any of this stuff
anywhere. The attribute abi_tag is documented in the gcc manual.
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes
You perhaps care more about how libstdc++ uses it, which isn't in the
gcc manual. I do see two mentions in the libstdc++ docs
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
https://gcc.gnu.org/onlinedocs/libstdc++/manual/api.html

Right, that's more information than is linked in the bug, I'll do that
now, thanks for the pointers.

But I suspect the people involved already knew this from an early
stage (maybe even since 2012). The problem is not the change per se,
but how the change was done.

The design remained undocumented and was agreed upon on meetings
between GCC and the Distros. The distros decided to move, didn't think
about Clang, and now they're whining that Clang doesn't work.

Even though the GCC folks should have discussed such a big change with
(at least) Clang folks, it's the distro folks that should have given a
damn about this whole issue.

Again, thanks for the detailed response, I'll update the bug report.

cheers,
--renato