Remove MK_CHERI #1762
Remove MK_CHERI #1762
Conversation
The software still has these bugs, but upstream compilers now error on them by default so we're supressing these warnings without the need for local changes.
|
Does MK_CHERI even serve a real purpose at this point? It's just gating libsyscalls and various things in bin. The only thing I could imagine is if libsyscalls is broken for non-CHERI architectures, but libsyscalls itself has nothing really to do with CHERI beyond being a thing that libcheri wanted to use. |
Tests are now believed to run reliably enough to just enable them.
brooksdavis
force-pushed
the
cleanup-MK_CHERI
branch
from
de3f22d
to
3937926
Compare
Prodded by this comment I've removed the WITH(OUT)_CHERI option entirely. |
brooksdavis
force-pushed
the
cleanup-MK_CHERI
branch
from
3937926
to
152279e
Compare
|
This will conflict with #1761 and completing the change (with src.conf.5 updates) depends on that PR. |
It should work on all platforms, but is currently broken on amd64 so just enable on CHERI platforms where it is currently required.
Don't use MK_CHERI to gate the build of small(ish) programs and instead use the target CPU and ABI.
The CHERI option mostly did things orthoginal to CHERI_REVOKE support and now does nothing so remove the dependency.
It only gates code already gated by appropriate CPU and ABI flags and these small programs aren't things we're going to want to turn off any time soon.
brooksdavis
force-pushed
the
cleanup-MK_CHERI
branch
from
152279e
to
2b4188a
Compare
MK_CHERI used to be the all-purpose way to say you're building with CHERI. We now have a more mature model using MACHINE_CPU and MACHINE_ABI and MK_CHERI is supposed to enable odd bits of CHERI-specific software. This PR removes the last uses that do otherwise.
Inspired by #1761