RFC 1: CHERIoT target nomenclature

[xdoardo]

Summary

We need to decide whether we want to follow the nomenclature that Clang/LLVM use for CHERIoT targets or not.

Until a short while ago, we used riscv32cheriot-unknown-cheriotrtos as the "default" triple to identify the CHERIoT target + the RTOS platform.

Following an RFC to LLVM, it seems that we'll have to move away from it: clang, for example, will use riscv32-unknown-cheriotrtos; this triple would be (if I'm not missing anything) enough for clang to infer that it means "I'm targeting the CHERIoT CPU, with the CHERIoT ABI". For the bare-metal target - riscv32-unknown-unknown - additional flags such as -mcpu, -mabi or -march will have to be specified by the user.

Now, for what concerns the triple we're currently adding there's not a lot to discuss, since it has -cheriotrtos which already makes it clear, to some extent, that its default target cpu will be CHERIoT; therefore, having a riscv32- instead of having a riscv32cheriot- prefix doesn't change the default target, and should not change much to the end users. Notably, that PR internally already uses the nomenclature without the cheriot bit after riscv32, and instead the combination of -cheriotrtos and the -xcheriot feature informs LLVM that the target platform is CHERIoT.

Later, however, we will want to add a bare-metal target to Rust as well: at that point, we'll have to decide between adding a new riscv32cheriot-unknown-unknown (or riscv32-unknown-unknown) target to Rust, or use triples that already exist like riscv32e-unknown-none-elf. If we decide to go for a triple that has no explicit ties with CHERIoT, users will then be expected to use rustc flags such as -C target-cpu=cheriot to specify that they want to compile to CHERIoT.
In turn, this could also require non-trivial changes in the code to check whether the actual target architecture is CHERIoT: for example, I imagine we would need to check if that's the case to correctly patch the default data layout string for the triple, the default address space and same for the default families of the triple.

CHERIoT target nomenclature in Rust

It seems, to me, that in rustc-land we can pretty much decide which name fits better the Rust ecosystem, as long as we use the correct LLVM nomenclature under the hood. This would, of course, introduce a discrepancy with respect to clang.

Thus, my proposals are:

• riscv32cheriot-unknown-cheriotrtos + riscv32cheriot-unknown-none-elf; or
• riscv32cheriot-unknown-cheriotrtos + riscv32cheriot-unknown-unknown; or
• riscv32e-unknown-cheriotrtos + riscv32e-unknown-none-elf; or
• riscv32e-unknown-cheriotrtos + riscv32e-unknown-unknown.

[seharris]

I have two suggestions for things we may want to think about in relation to deciding between riscv32e and riscv32cheriot.

It looks like Cargo only supports target options through rustflags in a Cargo config file, meaning Cargo itself has limited awareness of -C target-cpu. I imagine that works ok for lots of use-cases, but I'm suspicious there will be edge cases where it will cause complications. I don't know of any concrete examples so with any luck I'm wrong!

While this isn't directly relevant to anything we'll need during this project, it also doesn't look like Rustup would work well with this shape of target naming. I think Rustup works in terms of targets, so installing the vanilla riscv32e-unknown-none-elf target would have to also install the tooling for the any CHERIoT target using the same target name. I guess that wouldn't be terrible, but it seems like it could cause complications for the implementation of Rustup and make life more difficult for users.

[xdoardo]

Good point, I didn't think about rustup. In my opinion having cheriot-scoped triple names is fine; even if it diverges from LLVM's target triple. I forgot to add this to the introduction above, but other targets in rustc behave exactly in the same manner. For example: 1, 2.