The biggest reason, I guess, is inability to reliably handle all the madness C++ ABI can conjure. Hell, you can break ABI without even changing class layout. My favorite example of this is making TrivialType class non-trivial.
Conversation
Replying to
Not in the sense of ABI compatibility though. Compilers produce *some set of bytes* that *most often* works as expected, but sometimes still blows everything up. AFAIK there are no ABI analysis tools whatsoever (on the level where you check if ABIs for two _source_ files match).
2
Android has it for Treble as part for enforcing that C++ HAL ABIs are backwards / forwards compatible.
1
2
I did hit an issue where enabling -ftrivial-auto-var-init=zero caused a minor change that broke the checks and I had to regenerate the ABI information. The failure was a very minor issue and I just applied a very blunt fix for the problem since this isn't relevant to us anyway.
1
2
It was a minor false positive with libprotobuf-cpp. I regenerate the ABI specs so it looks like there's a huge amount of churn but it was really some super minor thing and it's just totally irrelevant to us so why not work around it the easiest way:
github.com/GrapheneOS/pla
1
source.android.com/devices/archit is some of the documentation. Maybe useful to someone as a starting point. It doesn't have much relevance to my work and my awareness of it is limited to my annoyance at the added build time (esp. clean builds) and this *one time* it had a false positive.
2
2
You can run header-abi-dumper / header-abi-linker / header-abi-link standalone and they actually have help output. No idea how to use them and need to stop thinking about this before I have nightmares about C++ though. IIRC each tool is an extended build of Clang? *shrug*
1
2
They want to make an ABI compatibility guarantee / verification system for Linux kernel modules too, at first within an LTS branch and then between them. At least for that there isn't a need to deal with the hellish reality of C++, just upstream deliberately trying to screw you.
1
2
Would really not be surprised if the kernel driver HAL was C++ and vendors just start writing all their kernel drivers for it. I think they'll continue requiring them all to be open source but if they implement the HAL for Fuchsia it'd mean those drivers aren't Linux derivatives.