Architecture support (tracking issue)
geofft opened this issue · comments
Rust supported architectures: https://forge.rust-lang.org/platform-support.html For our purposes, we don't care much about Tier 1 vs. Tier 2, and even Tier 3 support is probably fine.
Another useful reference is Debian's arch status as of February 2018: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2018-February/001215.html (doesn't include all the arches the kernel supports)
| arch | description | LLVM status | Rust status |
|---|---|---|---|
| alpha | DEC Alpha | removed from LLVM in 2011 | |
| arc | Synopsys ARC | present | needs port |
| arm | ARM 32-bit | present | ARMv5 and up is Tier 2 |
| arm64 | ARM 64-bit aka AARCH64 | present | Tier 2 |
| c6x | TI C6000-series VLIW DSPs | no LLVM port | |
| csky | C-Sky | no LLVM port | |
| h8300 | Hitachi H8 | no LLVM port | |
| hexagon | Qualcomm Hexagon DSP, part of Snapdragon SoCs | present | added July 2019 |
| ia64 | Intel Itanium | removed from LLVM in 2009 | |
| m68k | Motorola 680x0 | port exists, proposed for merge | work in progress |
| microblaze | Xilinx MicroBlaze for FPGAs | removed from LLVM | |
| mips | MIPS (R3000 / MIPS I and up) | present for R4000 / MIPS II and up | Tier 2 |
| nds32 | Andes AndeStar 32-bit | proposed for merge in 2017 | needs port |
| nios2 | Altera Nios II for FPGAs | removed from LLVM in January 2019 | |
| openrisc | OpenRISC | out-of-tree backend | needs port |
| parisc | Hewlett-Packard PA-RISC aka hppa | no LLVM port | |
| powerpc | PowerPC / POWER 32-bit, 64-bit LE, 64-bit BE | all present | all Tier 2 |
| riscv | RISC-V | present | Tier 2 |
| s390 | z/Architecture 64-bit aka s390x | present | Tier 2 |
| sh | Hitachi SuperH / J2 | experimental out-of-tree backend | needs port |
| sparc | Sun SPARC 32- and 64-bit | present | Tier 2 for 64-bit (SPARC v9), needs 32-bit port |
| um | User-Mode Linux (on any userspace arch) | N/A | might just work? |
| x86 | Intel x86 aka i386 and x86-64 aka amd64 | present | Tier 1 |
| xtensa | Tensilica Xtensa, used on ESP microcontrollers | proposed for merge in March 2019 | work in progress |
Re ARMv4 - the linked issue implies ARMv4 is only a microcontroller for OS-less use, but arch/arm/mach-gemini/ looks like an actual Linux target for ARMv4. There are also a few ARMv4T boards (i.e., with Thumb support). It looks like LLVM wants to emit BLX instructions which switch to Thumb mode, so unclear if plain ARMv4 will work. (Though forcing it to emit non-Thumb code only doesn't sound like it should be too difficult....)
Re MIPS I - see simias/psx-sdk-rs#1. MIPS I has load delay slots, LLVM's codegen would need to be taught about it. https://github.com/impiaaa/llvm-project seems to have a patch.
Some possible approaches for merging into mainline and dealing with architectures with no LLVM support and no realistic plans (e.g., processors no longer manufactured):
- Convince Linux to drop them <_< >_>
- Only support certain architectures via Kconfig - it's probably okay to only support some modules on the major architectures
- Use mrustc to compile via C https://github.com/thepowersgang/mrustc
- Use the LLVM C backend to compile via C #111
- Write a GCC frontend for Rust, see https://github.com/sapir/gcc-rust/tree/rust (which glues actual rustc into GCC) or https://github.com/redbrain/gccrs, both of which seem to be actively developed
- Something involving Cranelift, maybe? I don't have a good sense of what this would look like / whether it would work.
Note, Hexagon was added in the Rust compiler: rust-lang/rust#62814
So might me just worth testing the support.
Note, Hexagon was added in the Rust compiler: rust-lang/rust#62814
So might me just worth testing the support.
My work to get hexagon-linux support for rust is incomplete, I still have to work out changes to libc and possibly more beyond that.
But the good news is that codegen support for the hexagon processor in general has been present in the compiler for a while. My recent changes were only for making userspace binaries. AFAIK the codegen support that was added by @michaelwu (around rust-lang/rust#41524) should suffice for kernel module development.
Unicore has been removed in torvalds/linux@0511921.
@nickdesaulniers says arc, hexagon, riscv, s390, and sparc are currently broken in ClangBuiltLinux CI (although support exists). I wonder if the breakage would affect Rust.
C-SKY LLVM port got proposed in August 2020.
Convince Linux to drop them << >>
Removing support for some of these architectures from the Linux Kernel is currently being discussed - Old platforms: bring out your dead