Conor Dooley <conor@xxxxxxxxxx> writes: > From: Conor Dooley <conor.dooley@xxxxxxxxxxxxx> > > I've intentionally not turned on the gcc support, as discussed on > v1. I've also switched over to using the target, but it is a bit heavier > than the one arm64 seems to be using. RISC-V has fewer targets available > and this was the closest. I preserved the redzone disabling, just moved > into the Makefile. Any comment from Gary or the LLVM lads on the target > would be great I think: > https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/targets/riscv64imac_unknown_none_elf.rs > arm64 is using: > https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/targets/aarch64_unknown_none.rs > > I was gonna send this yesterday, but found out last minute I had invalid > code in the target generation script. The kernel test robot had given my > branch the global all-clear - the rust coverage with all the > "depends on !FOO" must really limit the build coverage. I built for x86 > with rust enabled locally this time to make sure.. > > As this as lifted from the state of the Rust-for-Linux tree, the commit > messages from there cannot be preserved, so these patches have commit > messages that I wrote. > > I've tested this on Icicle, and the modules seem to work as expected. > Unfortunately there appear to be implicit 32-bit divisions (or similar) > in core Rust code, so, as in the downstream Rust-for-Linux tree, Rust is > only enabled for 64-bit. Nice, works with my simple test on VisionFive 2 as well! Cool to have Rust support in! Now, BTF just needs to be supported, and I can have Rust *and* BPF in my kernels! :-P \o/ Tested-by: Björn Töpel <bjorn@xxxxxxxxxxxx>
