Conversation

can someone tell me why c++ compilers don't checksum class layouts to let the linker warn you if you've fucked up ABI compatibility? ocaml does this, works well

Quote Tweet

the answer is that i forgot to pass an option to my code generator, so half of the compiled code used one (up to date) class definition inline in the source file and the other half of the compiled code used another (outdated) class definition in the header file infuriating

Show this thread

8

8

77

@newplayer123123

Replying to

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.

1

Replying to

@newplayer123123

C++ compilers and linkers already handle the C++ ABI, that's their job

1

@newplayer123123

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

Replying to

@newplayer123123

and

Android has it for Treble as part for enforcing that C++ HAL ABIs are backwards / forwards compatible.

1

2

Replying to

@newplayer123123

and

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

Replying to

@newplayer123123

and

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

Replying to

@newplayer123123

and

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.

source.android.com

ABI Stability | Android Open Source Project

2

2

Replying to

@newplayer123123

and

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

Replying to

@newplayer123123

and

android.googlesource.com/platform/devel

7:05 PM · May 26, 2020Twitter Web App

Replying to

@newplayer123123

and

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

Replying to

@newplayer123123

and

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.

1