Add support for the CHERI-LLVM toolchain for RV32 baremetal apps #4
Conversation
config/registration.bzl
Outdated
| load("@crt//toolchains/gcc_mxe_mingw64:repository.bzl", "gcc_mxe_mingw64_repos") | ||
| load("@crt//toolchains/cc65:repository.bzl", "cc65_repos") | ||
|
|
||
| def crt_register_toolchains( | ||
| arm = False, | ||
| m6502 = False, | ||
| riscv32 = False, | ||
| cheri_llvm = False, |
There was a problem hiding this comment.
I think this should be named something like riscv32_cheri.
There was a problem hiding this comment.
The CHERI LLVM toolchain can also generate riscv64 binaries, and even mips64 binaries (although this is almost never used nowadays) so I would hesitate to tie the name to riscv32.
The steps described in the README for building the archive specifically build libraries etc. that target riscv32+cheri, but they could be extended to also build the requirements for riscv64+cheri baremetal, mips64+cheri baremetal or even vanilla riscv32/64 and the built archive could then be used for any of those targets, so I think a more generic toolchain name is more appropriate.
Let me know your thoughts.
There was a problem hiding this comment.
What we're adding in this PR is a particular toolchain configuration that informs bazel about how to select and run the compiler to emit riscv32 code with cheri features.
When/if we get to the point of having riscv64+cheri or mips64+cheri or x86_64+cheri, we'll need to add those as separate configurations (note that these configurations could indeed be backed by a single compiler and appropriate constraints to select the proper feature set per configuration).
There was a problem hiding this comment.
At the risk of annoying your half-to-death with requests to change the directory structure, it sounds like it might be appropriate to change platforms/riscv32/cheri/... to platforms/cheri/riscv32/.... That would allow for the creation of a riscv64, mips64 and whatever else under the platforms/cheri directory.
I still think the appropriate name here (in crt_register_toolchains) is a combination of cheri and the architecture name. Even if you did eventually support a bunch of architectures with cheri options, downstream projects would probably only want to enable the configuration that was appropriate to their CPU architecture.
There was a problem hiding this comment.
OK, this makes sense. I've committed changes to rename the argument cheri_llvm to cheri_riscv32 (the toolchain is still called cheri_llvm) and I've moved platforms/riscv32/cheri -> platforms/cheri/riscv32.
| Lastly, copy `cheri_llvm_sdk.tar.gz` to this folder. The name must match the | ||
| filename in the `archive` field in `../repository.bzl` |
There was a problem hiding this comment.
We should discuss how to allow you to provide the compiler archive without requiring it to be in this repository or requiring the user to take a repository modifying action (e.g. copying the file into this subdir). Modifying the repository as a build step is "bad".
There was a problem hiding this comment.
I've been thinking about how to allow you to supply the compiler archive without needing to ask the user to modify the repository. There are two mechanisms I can think of:
- Supply the repository yourself and forego the call to
cheri_llvm_repos()incrt_register_toolchains. In your WORKSPACE, you could then do something like this:
load("//third_party/crt:repos.bzl", "crt_repos")
crt_repos()
load("@crt//:repos.bzl", "crt_repos")
crt_repos()
load("@crt//:deps.bzl", "crt_deps")
crt_deps()
load("@crt//config:repo.bzl", "compiler_repository")
compiler_repository(
name = "cheri_llvm_files",
archive = "/path/to/your/cheri_llvm_sdk.tar.gz",
exports = [ ... ],
)
load("@crt//config:registration.bzl", "crt_register_toolchains")
crt_register_toolchains(riscv32_cheri = True)
- Modify the interface to
crt_register_toolchainsto allow you to pass the path to the compiler archive. Your WORKSPACE would then have something like:
crt_register_toolchains(
riscv32_cheri = "/path/to/your/cheri_llvm_sdk.tar.gz",
)
crt_register_toolchains can then pass the archive location on to cheri_llvm_repos() which will instantiate the compiler_repository.
I've been considering something like (2) for a while to enable end users to pass in alternate compilers, but I haven't yet had a need for it and I'd probably want to plumb things up a bit more to make the archive properties more configurable.
This moves the CHERI RISC-V 32b platform under riscv32, moves the "cheri" extension constraint into a new constraints/extension directory (since CHERI is not RISC-V specific) and uses the library_search_directories feature for CHERI libraries. It also makes the CHERI-LLVM target substitutable by devices.
Other versions of CHERI configurations (i.e. CHERI+RISCV64, CHERI+MIPS64 etc.) should be added under "platforms/cheri".
At the moment there is no toolchain archive available for the CHERI-LLVM toolchain, so instructions to create the archive are included in
toolchains/cheri_llvm/archive/README.md.