Re: [PATCH v2 3/3] rust: Enable for MIPS
From: Jiaxun Yang
Date: Tue Sep 10 2024 - 15:10:58 EST
在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