mips64-unknown-linux-gnuabi64 rustc unable to produce mips4 binary

[cyborgyn]

I am trying to compile rustc, and some applications written in rust for my SGI R10000 workstation, with 64 bit Linux on it.
Found out, that even though I specify -Ctarget-cpu=mips4 for rustc, it always produces MIPS64r2 binaries.
R8000 and later mips CPUs implement MIPS4 architecture, which is a subset of MIPS64 ISA and subset of MIPS32 ISA.

I found, that the default settings in https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/mips64_unknown_linux_gnuabi64.rs is too restrictive, and it seems one can not downgrade by passing target-cpu parameter, what is defined in this file (even though, mips3 was the first ISA to support 64bit instructions), and by passing, it silently ignores, and generates executables:

ELF 64-bit MSB pie executable, MIPS, MIPS64 rel2 version 1 (SYSV), dynamically linked, interpreter /lib64/ld.so.1, for GNU/Linux 3.2.0, not stripped�

By applying a simple patch like this:

--- compiler/rustc_target/src/spec/mips64_unknown_linux_gnuabi64.rs.old        2021-09-14 16:20:48.323014516 +0200
+++ compiler/rustc_target/src/spec/mips64_unknown_linux_gnuabi64.rs    2021-09-14 16:21:43.482314818 +0200
@@ -10,8 +10,8 @@
         options: TargetOptions {
             endian: Endian::Big,
             // NOTE(mips64r2) matches C toolchain
-            cpu: "mips64r2".to_string(),
-            features: "+mips64r2".to_string(),
+            cpu: "mips4".to_string(),
+            features: "+mips4".to_string(),
             max_atomic_width: Some(64),
             mcount: "_mcount".to_string(),

I was able to finally compile executables for R10000 CPU:

ELF 64-bit MSB pie executable, MIPS, MIPS-IV version 1 (SYSV), dynamically linked, interpreter /lib64/ld.so.1, for GNU/Linux 3.2.0, not stripped

And the -Ctarget-cpu=mips64r2 also worked, to generate what was before the default.

I propose to lower the default / minimum required CPU from mips64r2 to mips3, or mips4.

[cyborgyn]

Patch in pastebin: https://pastebin.com/nL7uVdYs

[nagisa]

Typically the way defaults are chosen here is by using similar ones as those the most widely used distributions use. It seems like Debian at least targets MIPS IV, so I think we'd have no issue with merging a PR to adjust the target.

[nagisa]

As for the compiler flags, -Ctarget-cpu=mips4 -Ctarget-feature=-mips64r2,+mips4 might do it?

[cyborgyn]

As for the compiler flags, -Ctarget-cpu=mips4 -Ctarget-feature=-mips64r2,+mips4 might do it?

For me, I would also be very happy, if it would work. But unfortunately, it does not. Tested the exact same parameters, and without the patch, it still produced MIPS64 rel2 binaries. I suspect, there must be somewhere a target-cpu parameter validation hidden in the code, which silently (a.k.a. without warning, or error messages) removes the parameter, before it can be assigned to the LLVM target, thus the default comes into play. Which would actually make sense, in the case of mips2 or mips1 target, which is clearly not 64bit capable. A similar silent ignorance of - otherwise listed - CPU targets, can be observed in x86-64 code generation, where you can specify i686, i586, even i386, but still sticks to x86-64 +sse +sse2 code generation.

[sanxiyn]

@nagisa cc @infinity0 Are you sure about Debian? https://wiki.debian.org/MIPSPort suggests mips64 (MIPS, 64-bit, big endian) is not supported by Debian. I am actually unsure which distribution is widely used for mips64.

[nagisa]

Not entirely sure where I found that information. In retrospective I should've linked my sources ^^.