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

["Jiaxun Yang" <jiaxun.yang@flygoat.com>]

在2024年9月10日九月 下午5:03，Maciej W. Rozycki写道：
> On Mon, 9 Sep 2024, Jiaxun Yang wrote:
>

>> >  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.

>
>> 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....

>
>> 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