rustc: Remove soft-float from MIPS targets

[alexcrichton]

Right now two MIPS targets in the compiler, mips-unknown-linux-{gnu,musl} both
generate object files using the soft-float ABI through LLVM by default. This is
also expressed as the -C soft-float codegen option and otherwise isn't used
for any other target in the compiler. This option was added quite some time ago
(back in #9617), and nowadays it's more appropriate to be done through a codegen
option.

This is motivated by #34743 which necessitated an upgrade in the CMake
installation on our bots which necessitated an upgrade in the Ubuntu version
which invalidated the MIPS compilers we were using. The new MIPS compilers
(coming from Debian I believe) all have hard float enabled by default and soft
float support not built in. This meant that we couldn't upgrade the bots
until #34841 landed because otherwise we would fail to compile C code as the
-msoft-float option wouldn't work.

Unfortunately, though, this means that once we upgrade the bots the C code we're
compiling will be compiled for hard float and the Rust code will be compiled
for soft float, a bad mismatch! This PR remedies the situation such that Rust
will compile with hard float as well.

If this lands it will likely produce broken nightlies for a day or two while we
get around to upgrading the bots because the current C toolchain only produces
soft-float binaries, and now rust will be hard-float. Hopefully, though, the
upgrade can go smoothly!

[rust-highfive]

r? @nrc

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

r? @brson

cc @japaric

[brson]

@bors r+

[bors]

📌 Commit 617c65e has been approved by brson

[japaric]

I can't really speak for the mips-gnu target because I am not familiar with the Linux distributions that exist for that target but I guess it makes sense to follow Debian/Ubuntu and use the hard float ABI.

But for mips-musl, one of the main use cases is OpenWRT and AFAICT most OpenWRT releases (for several, different devices) use the soft float ABI so I don't think it makes sense to change the ABI from soft to hard. Furthermore, the mips-linux-musl-gcc toolchain in the rust-buildbot is using the soft float ABI. (I'm assuming this is, indeed, changing the mips-musl target from the soft float ABI to the hard float ABI, if that's not the case carry on!)

[alexcrichton]

@japaric thanks for the info! This does indeed change mips-musl, but I will revert

[alexcrichton]

@bors: r=brson

@japaric as a side note, should the mipsel musl target also have soft float?

[bors]

📌 Commit f77bcc8 has been approved by brson

[japaric]

@alexcrichton I did a survey of the OpenWRT musl releases and all the mips (8 devices) and mipsel (12 devices) releases are using the soft float ABI.

So, yes. We should change the mipsel-musl target to soft float as well.

[japaric]

So, yes. We should change the mipsel-musl target to soft float as well.

I should note that the Rust mipsel-musl backend target is using the hard float ABI and the C cross toolchain is also using the hard float ABI, so we need to update both the target definition (+soft-float) and "tweak" the cross toolchain. "Tweak" as in (a) rebuilt the cross toolchain or (b) pass some extra flag (-msoft-float?) to the cross toolchain to force the use of the soft float ABI. I think you've tested option (b) with the mips-gnu toolchain and it didn't work though.

[alexcrichton]

Ah ok, confirmed that -msoft-float doesn't work on the mipsel-musl toolchain. I'll open a bug about this and otherwise we can keep the status quo for now.

[alexcrichton]

Ok, opened up #34922

[nagisa]

I feel like mips{,el}-unknown-linux-{musl,...} targets being tailored for what really should be a mips{,el}-unknown-openwrt-... (or -openwrt-linux-) is a mistake. We should investigate what the more conventional Linux distributions targeting MIPS do and use that, while also creating soft-float targets for openwrt.

Sure, OpenWRT still uses linux kernel, but I wouldn’t call it close enough to Linux-the-OS.

[alexcrichton]

@nagisa perhaps yeah, but with a lack of demand I don't think it matters too much one way or another at the moment, we can always tweak in the future.

This is just indicative of how our target specs are not super well defined, and probably won't get solved here either way.

[nagisa]

I’d still insist somewhat on making the soft-float targets be named properly, especially now that we know exactly where they are used and do have demand. mips*-openwrt-linux-* would represent the soft-float targets very well.

[alexcrichton]

PRs are of course always welcome! @japaric should be cc'd but I don't see too much in the way otherwise.

[japaric]

IMO, we should have (at least) two releases: one for soft float and another for hard float. Also, I don't think we should conflate the vendor (*-openwrt-*-*) with the ABI. Yes, all OpenWRT MIPS(el) releases happen to be soft float today, but there may be hard float releases in the future.

The "problem" I see with one release per ABI is naming. gcc uses the same triple (mips-unknown-linux-gnu) for all the different ABIs but because of how rustup works we can't use the same triple for different binary releases. We could use mips-unknown-linux-musl and mips-unknown-linux-muslhf to differentiate them but I don't recall ever seeing the muslhf component in a triple (there is musleabi and musleabihf, but those are ARM exclusive).

Then, there is the issue that there are a few MIPS ABIs: 32, o64, n32, etc. (cf. gcc options, look for -mabi=) and there are also a few FP ABI variants. As Rust gets more use on MIPS, we'll probably start seeing demand for different ABIs; this means demand for more mips(el)-musl releases...

[bors]

⌛ Testing commit f77bcc8 with merge b3707ff...

[bors]

💔 Test failed - auto-win-gnu-32-opt-rustbuild

[alexcrichton]

@bors: retry

• Cascading failure on bots when interrupted when performing git operations #34595

On Tue, Jul 19, 2016 at 9:36 PM, bors notifications@github.com wrote:

💔 Test failed - auto-win-gnu-32-opt-rustbuild
https://buildbot.rust-lang.org/builders/auto-win-gnu-32-opt-rustbuild/builds/1828

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#34910 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAD95D-4RJBdBgPZm6bl0BpIEtOUTRHWks5qXaW5gaJpZM4JPPYw
.

[alexcrichton]

@bstrie I'm gonna remove this from the "MIR into Orbit" milestone b/c this isn't directly blocking it, we can always deal with the fallout here later and in parallel.

@bors: rollup

[bors]

⌛ Testing commit f77bcc8 with merge 77ba66d...

[bors]

💔 Test failed - auto-linux-64-cargotest

[alexcrichton]

@bors: retry

On Wed, Jul 20, 2016 at 6:24 PM, bors notifications@github.com wrote:

💔 Test failed - auto-linux-64-cargotest
https://buildbot.rust-lang.org/builders/auto-linux-64-cargotest/builds/1201

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#34910 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAD95G25Vpq80nGYT0nEouWw9_a72eAhks5qXspAgaJpZM4JPPYw
.