[RFC][Clang] Flag for Switching between C++ ABIs

Clang Frontend
1

Hi all,

We would like to propose a new frontend flag for Clang that would switch between different C++ ABIs. Right now, Fuchsia is in the process of switching between the Itanium C++ ABI and the Fuchsia C++ ABI, which would include Relative VTables. We would find it useful to have a single generic compiler flag that would select between the target’s default ABI and other ABIs.

The flag would look something like -fc++-abi= and override the default C++ ABI selected by the target. It’s up to the user to make sure that the ABI and target combination makes sense.

We think this would be useful for applications that want to migrate away from Itanium or experiment with other ABIs that their platform supports. With this flag, the only thing we would ideally need to change in our build would be adding -fc++-abi=fuchsia as a compile flag, and this would switch on any features we want to ship with the new Fuchsia C++ ABI.

Implementation-wise, there already exists an enum in TargetCXXABI that contains different ABIs, so we can expose them through this flag. More values can be added in the future to represent new experimental ABIs, such as Itanium V2.

Thoughts and opinions? Nothing here is set in stone and we welcome feedback.

Thanks,

Leonard

2

I like this idea and I know people in the retrocomputing and alt-OS community would find it useful. (Example: Haiku binary compatibility with BeOS is currently implemented by using a very old GCC. This would allow easier experimentation with implementing a compatible ABI in a modern compiler.)

Should it be specific to the C++ ABI though? Or should there be an equivalent for C ABI? (Example: The LLVM 68000 back-end that’s in progress currently targets the SVR4 ABI, but users of the compiler will definitely want support for Amiga, Atari, classic Mac OS, Sun, HP, etc. ABIs.) I suppose for C this is implied by the target triple, but it might be useful to have a separate switch for it.

– Chris

3

Should it be specific to the C++ ABI though? Or should there be an equivalent for C ABI? (Example: The LLVM 68000 back-end that’s in progress currently targets the SVR4 ABI, but users of the compiler will definitely want support for Amiga, Atari, classic Mac OS, Sun, HP, etc. ABIs.) I suppose for C this is implied by the target triple, but it might be useful to have a separate switch for it.

I’m not opposed to having an equivalent C flag for controlling C ABIs. I figured we could start off with one for C++ then incrementally add more options as people demand them.

4

The feature we are proposing is entirely about the C++ ABI, which is wholly an issue in the front end. The “C ABI” is really the target-specific language-independent ABI underlying all language front ends. There are various switches that affect that already and having a more straightforward one to collect various ABI concerns might be a worthwhile feature. But I think that is entirely orthogonal to the C+±specific issues we are discussing here.