Re: [PATCH v2 3/3] rust: Enable for MIPS

在2024年9月10日九月 下午5:03，Maciej W. Rozycki写道：

On Mon, 9 Sep 2024, Jiaxun Yang wrote:

quoted

quoted

 What's the consequence of using `mips2' rather than `mips1' here?  How 
about other ISA revisions, e.g. `mips4' (that also applies to the 64BIT 
leg)?

LLVM's mips1 backend is a little bit broken beyond repair, so I tried to use mips2
as a baseline. I should probably let HAVE_RUST depend on !CPU_R3000 to get it covered.

 GCC works just fine I suppose, just as with the other language frontends, 
doesn't it?

Nah, currently we can only use rustc with LLVM backend. target.json file
we are generating here is also LLVM backend only for rustc.

gccrs is not usable for kernel yet.

quoted

We have no good way to tell ISA reversion prior to R1 just from Kconfig TARGET_ISA_REV,
valid numbers for TARGET_ISA_REV are only 1, 2, 5, 6 from Kconfig.

 This approach doesn't work for some MIPS architecture processor configs 
anyway, e.g. what ISA revision will CPU_P5600 imply here?

TARGET_ISA_REV will be set to 5 for CPU_P5600 (CPU_MIPSR5 will default to y
on CPU_P5600, and CPU_MIPSR5 sets TARGET_ISA_REV to 5). 

 However if there's a need (and previously there wasn't), then I think it 
can be sorted in a straightforward way.  We have just a bunch of CPU_* 
settings and we can define corresponding ISA_* settings to select, e.g. 
ISA_MIPS1, ISA_MIPS3, ISA_MIPS32_R1, ISA_MIPS64_R6, and so on, based on 
information extracted from per-CPU_* `-march=' compilation flags from 
arch/mips/Makefile (possibly combined with ISA data obtained from 
GCC/binutils for said flags).

 It could be a bit tedious to write, but not a big challenge really, just 
mechanical work.

TARGET_ISA_REV is guaranteed to be aligned with CPU's supported ISA for now,
so I see no reason to invent another set of symbols....

quoted

Given that mips 2 and 3 binaries (Rust object files) can link run flawlessly on all pre-R6
(despite R3000) hardware with matching bitness, they were chosen as fallback here.

 I'm fine with having a MIPS1/R3000 exception for broken LLVM, but I see 
no reason to disable it for GCC.

It actually reminds me that LLVM lacks R4000 and some other workarounds as well.
I shall fix those in Kconfig as well.

Thanks

  Maciej

-- 
- Jiaxun