Refine CHERI macro and feature definitions

[brooksdavis]

This set of changes does three main things:

• adds an __CHERI_HYBRID__ to indicate hybrid compilation
• adds an __has_feature(cheri) to eventually replace the overly generic __has_feature(capabilities)
• Makes __CHERI__ a synonym for __CHERI_PURE_CAPABILITY__ and adds an __CHERI_HYBRID__ This is a breaking change

Rationale: We strongly encourage all CHERI consumers to use a pure-capability ABI whenever possible. Therefore it should be the easiest thing to type and less preferred options should be longer. The existing macros date to the earliest compiler support which barely supported capability types. Before broad adoption of CHERI we should make the macros be sensible. We're past Stuart Feldman's too many users of make to change the tabs threshold (12), but few codebases will be effected and the required changes are simple and can be safely performed automatically. We shouldn't have to live with this aspect of history forever.

[brooksdavis]

This should probably be split into two changes, the backwards compatible changes to __CHERI__ use so we can pull them into CheriBSD and the breaking changes.

[arichardson]

I do wonder if we want to use __has_feature(cheri) ? Capabilities seems rather generic and may be difficult to upstream

[heshamelmatary]

I do wonder if we want to use __has_feature(cheri) ? Capabilities seems rather generic and may be difficult to upstream

I agree on that. It's rather confusing for systems like seL4 that already have their own notion/definition/types for a capability.

[arichardson]

Technically this is a major breaking change but I don't think there is much choice outside of cheribsd that uses it so LGTM if @jrtc27 is also happy with it

[arichardson]

Could we add a test for the new hybrid macro here? And maybe update the RUN lines for RISC-V instead of MIPS? But that can be done in a future commit

[arichardson]

Thanks for the new change, LGTM. Will wait for @jrtc27 for merging though

[heshamelmatary]

I used to use __CHERI__ whenever I wanted to guard or do something that applies to both purecap and hybrid. Some compatibility issues arise with using __has_feature with (old) GCC etc and broke legacy GCC builds. Those required some workarounds. eg:

#ifndef __has_feature
#define __has_feature(x) 0
#endif

This assumes all projects have some sort of a global shared header where this could be defined, but unfortunately this is not always the case.

Existing projects such as muslc [1], newlib, CHERI-Linux also still use __CHERI__. While an easy fix, but probably worth notifying the maintainers and/or fixing it ourselves.

[1] https://git.morello-project.org/search?search=__CHERI__&nav_source=navbar&project_id=122&group_id=6&search_code=true&repository_ref=morello%2Fmaster

[bsdjhb]

Note that this set of changes will actually make the GCC world happier as you can just use #if defined(__CHERI__) || defined(__CHERI_HYBRID__) in place of #if __has_feature(cheri) if desired once they are adopted.

[arichardson]

Note that this set of changes will actually make the GCC world happier as you can just use #if defined(__CHERI__) || defined(__CHERI_HYBRID__) in place of #if __has_feature(cheri) if desired once they are adopted.

And that change can be made now even if they want to support the older compiler versions.