[PATCH] D93668: [clang] Override the Fuchsia platform ABI using the triple environment

Leonard Chan via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Jan 19 11:40:47 PST 2021


leonardchan added a comment.

In D93668#2492081 <https://reviews.llvm.org/D93668#2492081>, @phosek wrote:

> I agree that if we want to allow selecting C++ ABI only, a flag like `-fc++abi=` with some additional checks to disallow invalid combinations is better. The question is whether we want to allow that in the first place? The motivation behind this change is to support generating code that's ABI compatible with the code generated by GCC. That could be expressed using the target triple (one idea is to use `*-*-fuchsia-gnu`), which would cover both C++ ABI as well as other aspects of the ABI (for example it could also disable SafeStack/ShadowCallStack) so developers don't need to concern themselves with all the details of the ABI, which could evolve over time expanding the set of flags you'd need to pass to the compiler to generate code that's ABI compatible with GCC.

In the context of representing the fourth component of the triple to represent the *platform* ABI rather than exclusively the C++ ABI, I think this would make sense. Using this other component would essentially just mean adding another layer of default flag configurations whose default values differ from those set by the first three components. I think we'd only want to have this extra layer if we have a sizable number of flags that we'd want separate from the default triple.

For our case, I think this mainly includes

- the C++ ABI (which encompasses "return this" on ctors/dtors and relative vtables),
- SS/SCS
- and maybe the PIC-friendly lookup tables if that ends up getting hidden behind a switch

but there could be new ABI changes down the line that could fall under this (or others that exist now but don't come to mind right now). Unless I'm missing some other features, this list seems fairly small and might not be worth tucking this under something that's meant to control a set of flags, but if we care more about being preventative from adding new flags, then it seems fine to just stick with using the triple.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93668



More information about the cfe-commits mailing list