[PATCH] D85802: [clang] Add -fc++-abi= flag for specifying which C++ ABI to use

Thu Dec 1 20:58:55 PST 2022

dblaikie added a comment.

So, some context for how this came up/what I'm trying to address:

So I started here: D117616 <https://reviews.llvm.org/D117616> (for the googlers playing at home, see: b/198958855 for the proximal motivation) - not packing non-POD members of packed structs.
That lead to D119051 <https://reviews.llvm.org/D119051> (changing the Itanium definition of POD to allow defaulted special member functions, to match GCC)
Which included a discussion <https://reviews.llvm.org/D119051#3834985> about where to implement this property (`areDefaultedSMFStillPOD`) - I guess I had it in `TargetInfo` initially, @rnk asked about whether I could move a related query (`getTailPaddingUseRules`) from `TargetCXXInfo` to `TargetInfo` to keep related things together.
I tried that refactor in D135326 <https://reviews.llvm.org/D135326>, chatted with @rjmccall about the TargetCXXABI abstraction and we were both confused/didn't know why the `-fcxx-abi` flag exists, though in favor of the TargetCXXABI abstraction existing, so that at least some things don't need to be duplicated between targets, but not that it should be varied within an operating system.
Which got me to this discussion here.

So these configurable dimensions are adding friction to development and risk targets not getting the ABI they probably want (for instance, Fuchsia's probably missed these GCC ABI fixes related to POD/packing). It's unclear which C++ ABI things need to go in the TargetCXXABI versus all the other stuff that's implemented in ItaniumCXXABI/MicrosoftCXXABI, etc. Though perhaps that can be addressed anyway, regardless of whether it's variable within an OS - though the latter does add to the confusion.

The way I'd picture this, with what I know at the moment, is that TargetCXXABI is only the parts of the ABI that are necessary during parsing (which explains why Itanium/MicrosoftCXXABI in clangCodeGen don't come up here - they're exclusive to codegen/don't impact the AST), and could be implemented as mixins to TargetInfo - different TargetInfos could inheret from different CXXABIs, but I guess they could compose to support this CXXABI-varying-within-OS, but complicates the interactions with the codegen CXXABI abstractions, I think.

It's awkward, I think, to have TargetCXXABI sort of have an ad-hoc target/abi enum inside it anyway - and maybe would be nice if it used inheritance/virtual functions the same as TargetInfo does. We could have an ItaniumTargetCXXABI that is whatever the purest form of that is we have at the moment, and parts could be overridden by targets that want particular subsets/old versions of that - though perhaps it'll be simple enough to say ClangVersionTargetCXXABI derives from ItaniumTargetCXXABI and overrides the few things based on the clang cxx-abi-version flag...

My understanding of the fuchsia situation is that there's a clang compiled project and the fuchsia floating ABI, but then a desire to build some code with GCC that doesn't implement that ABI - but GCC can't build everything (libc++ in particular) so you need to build that with clang, but targeting the GCC ABI. I would think/hope the way to address that would be to tell Clang you're targeting whatever OS GCC is targeting (though if I understand correctly that's a bit of a pain having to specify all the library paths, etc, from scratch like you have to do for GCC? But hopefully if you can do it for GCC you can do it for Clang in a similar way?). This might remove the need for Clang to support this use case & simplify Clang's already fairly complicated ABI handling & reduce the chance of divergence/ABI bugs being introduced to this complicated matrix of compatibility.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85802/new/

https://reviews.llvm.org/D85802