在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
