Standard macros to identify CHERI support and ABIs
kevin-brodsky-arm opened this issue · 6 comments
I think it would be quite helpful if the guide introduced a small set of macros that identify the available CHERI functionalities. CHERI LLVM already defines macros such as __CHERI_PURE_CAPABILITY__, but these are quite a mouthful and do not clearly distinguish between "support for functionality X is enabled" and "ABI Y is being used". To avoid impacting existing software, I would suggest keeping those built-in compiler macros and adding the ones proposed here to cheriintrin.h.
Support macros:
CHERI_SUPPORTED: CHERI architectural functionalities are available
ABI macros:
CHERI_ABI_HYBRID: the hybrid-cap ABI is used (impliesCHERI_SUPPORTED)CHERI_ABI_PURE: the pure-cap ABI is ued (impliesCHERI_SUPPORTED)
These lists could be extended to identify further functionalities and ABIs (e.g. descriptor-based).
Do you expect these to be 0/1 values or defined/not defined?
I agree that the current macros are rather long and can be annoying to type, but I'm not sure the new ones are that much easier to use. One benefit of adding them as 0/1 macros is that we could at least have -Wundef warn about typos.
CHERI_SUPPORTED == __has_feature(capabilities) /* Or defined(__CHERI__), but we are moving away from that */
CHERI_ABI_HYBRID == __has_feature(capabilities) && !defined(__CHERI_PURE_CAPABILITY__)
CHERI_ABI_PURE == defined(__CHERI_PURE_CAPABILITY__)
Also whether a descriptor ABI is in use or not is done based on the value of __CHERI_CAPABILITY_TABLE__.
I think it makes sense to have these as 0/1 values instead of defined/undefined, for the reasons that @arichardson mentioned. It also means that using them without including cheriintrin.h will cause a warning.
That's just asking for confusion given that's not how normal feature macros work, and you need to handle undefined correctly anyway to deal with non-CHERI compilers. I foresee people erroneously using #ifdef rather than #if and ending up doing the wrong thing for hybrid.
That's certainly the downside of it, that said this scheme doesn't support non-CHERI compilers anyway, since the macros are defined in cheriintrin.h (i.e. including it would fail in the first place).
That's certainly the downside of it, that said this scheme doesn't support non-CHERI compilers anyway, since the macros are defined in
cheriintrin.h(i.e. including it would fail in the first place).
Yes, I was in the middle of writing that when I got distracted by something else. Whatever we decide on for names (if anything different) should just be done as clang pre-defined macros like everything else IMO.