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
Hi Renato,
On 20 January 2016 at 12:38, Renato Golin renato.golin@linaro.org wrote:
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.
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
cheers, --renato _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
On Wed, Jan 20, 2016 at 3:49 AM, Yvan Roux yvan.roux@linaro.org wrote:
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-A... 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
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.
On 20 January 2016 at 23:05, Jim Wilson jim.wilson@linaro.org wrote:
It appears that a complaint from doko started this mess.
As usual... :)
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.
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.
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.
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-A... 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
linaro-toolchain@lists.linaro.org