Baremetal support #42

sleffler · 2024-09-18T17:29:59Z

This is the baremetal support I'm using to build OpenTitan and OT-based applications (available at opensecura.googlesource.com). These are tested in simulation.

There are XXX comments that are reminders for me; will remove after resolving feedback.

Include files are derived from cheriot-rtos; I've preserved the copyright.

clang/lib/Basic/Targets/RISCV.h

llvm/include/llvm/Support/Base64.h

llvm/lib/Target/RISCV/RISCVISelLowering.cpp

vmurali · 2024-09-18T18:45:18Z

clang/lib/Baremetal/CMakeLists.txt

Do we need a separate directory for Baremetal? The only change seems to be redefining _cheri*. And that is already protected by the CHERIOT_BAREMETAL macro. The compilation path could be the same as CHERIoT's default, except for using CCalls instead of CHERI_CCalls.

No, the clang headers are expected to work in all configurations. If we want clang to provide headers, we should fix the ones that clang provides to work with CHERIoT. I don't really want to do this, since we don't install the clang headers by default in the CHERIoT toolchain builds, I'd much rather that we change the RTOS headers to work with bare metal (which, I believe, requires a trivial change in cdefs.h to define the __cheri_libcalls and __cheri_compartment macros to nothing when in bare-metal mode.

I removed the baremetal subdir. I think it's a bad idea to tie baremetal compilation to cheriot-rtos (e.g. there are other potential os's that might be used with the toolchain). But I'm also not thrilled that install-baremetal-headers and install-clang-resource-headers overlap though it should be a noop (unless something depends on the file mod times).

I can remove the reach-over includes and just require the toolchain user install clang-resource-headers to get them.

Removed headers for now based on private discussion.

llvm/lib/Target/RISCV/RISCVISelLowering.cpp

Adds -mabi=cheriot-baremetal to support code that is to run before the CHERIoT loader runs and sets up compartments and the like. This assumes the user will handle processing the root capability, any capability relocation necessary, and all code runs in a single compartment. - builtin intrinsics use direct C calls (instead of __cheri_libcalls) - __cheri_libcalls are reduced to direct C calls (with a warning) - intrinsic memory op symbols (e.g. memcpy) are not mangled - (on debug builds) assertions guard against emitted code that violates baremetal assumptions (e.g. cross-compartment calls)

Global weak symbols can resolve to a Constant; guard against this.