-Csoft-float flag is unsound

[RalfJung]

@bjorn3 just made me aware of this amazing flag:

    -C               soft-float=val -- use soft float ABI (*eabihf targets only) (default: no)

This is quite unsound: if code gets compiled with -Csoft-float and calls code from the standard library that uses the hard float ABI, we have UB. Generally we need different target triples for softfloat vs hardfloat ABIs, since (as per the discussion in rust-lang/lang-team#235) code within a single target should be ABI compatible. Cargo even (unstably) allows overwriting RUSTFLAGS on a per-crate basis, so we better make sure crates compiled with different flags can be linked with each other.

This was added a looooong time ago in #9617. I couldn't find any discussion regarding its soundness.

We have e.g. arm-unknown-linux-musleabi and arm-unknown-linux-musleabihf, so using the *hf target but with -Csoft-float also seems kind of unnecessary. (But I have not checked whether all eabihf targets have a corresponding eabi target.)

According to the documentation, this can only be used by ARM targets. So paging in some ARM folks -- is this used in practice, and if yes, how do people avoid the soundness problems?
@rustbot ping arm

[rustbot]

Hey ARM Group! This bug has been identified as a good "ARM candidate".
In case it's useful, here are some instructions for tackling these sorts of
bugs. Maybe take a look?
Thanks! <3

cc @adamgemmell @hug-dev @jacobbramley @JamieCunliffe @joaopaulocarreiro @raw-bin @Stammark

[RalfJung]

Rustc just always forwards this flag to LLVM, so it seems possible that the *eabihf targets only part of the docs is not correct. We're certainly seeing a bunch of people out there setting this on non-ARM targets (e.g. here are some uses on x86 and riscv).

Cc @parched who added this part to the docs in #36261. Does LLVM document anywhere what this flag does, and which targets it affects?

[Dirbaio]

(hi from from the embedded side. i'm mostly familiar with the thumb*eabi(hf)? targets, i'm not sure about others)

One use of the flag is to allow using the FPU while still using the soft-float ABI for compatibility with other code. However, this can already be done by using the -eabi targets and then telling the compiler to use the FPU anyway with some -Ctarget-feature, which seems a much less dangerous way of doing it.

I can't think of any other uses, so I wouldn't oppose deprecating/removing it.

[RalfJung]

Seems like this flag is called -mfloat-abi in GCC/clang and indeed only exists for ARM. So most uses out there are bogus. A first step might be for us to show a warning when the flag is used on a target where it has no effect.

One use of the flag is to allow using the FPU while still using the soft-float ABI for compatibility with other code. However, this can already be done by using the -eabi targets and then telling the compiler to use the FPU anyway with some -Ctarget-feature, which seems a much less dangerous way of doing it.

Yes indeed, if there's a way to tell LLVM "use soft-float ABI but also use FPU", in a way that doesn't affect the ABI at all as is entirely link-compatible with fully soft-float code, then that's what should be done.

[RalfJung]

Hm, either I am misunderstanding the assembly or this feature does not work as advertised? https://godbolt.org/z/53W75s3fc seems to show that -Csoft-float does not actually change the ABI?

EDIT: Ah no I just can't read assembly. This still uses hard-float operations but first moves the data from rN to sN, i.e. it expects a soft-float ABI. Never mind.

[RalfJung]

Here are the eabihf targets that do not have a corresponding eabi target, and thus might rely on -Csoft-float to get a soft-float ABI:

• thumbv7neon-unknown-linux-gnueabihf (tier 2)
• armv6-unknown-netbsd-eabihf (tier 3)
• armv7-sony-vita-newlibeabihf (tier 3)
• armv7-unknown-netbsd-eabihf (tier 3)
• armv7-wrs-vxworks-eabihf (tier 3)
• armv8r-none-eabihf (tier 3)
• thumbv7neon-unknown-linux-musleabihf (tier 3)

So, only one tier 2 target is affected. And it's a tier 2 target without listed maintainers.

[bjorn3]

armv7-sony-vita-newlibeabihf is meant to be used with a single cpu only which supports floats, so there is probably no need for soft-float support for that target.

[thejpster]

Turning off the hard float ABI on a hard float target sounds like a "why do we even have that lever" kind of deal. I can't imagine why anyone would want to and I expect it would end badly if they tried.

As others have said, adding FPU instructions into a soft-float build is a entirely different matter, as is enabling Helium (MVE) or anything else that affects the juicy centre of a function but not its hard outer shell.

[thejpster]

On the Cortex-R52, the FPU is mandatory and if anyone wants compatibility with older soft-float code they can either use armv7r-none-eabi, or they can come and make a compelling case for the v8-R version (kernel developers? idk). I'm not minded to add it on a whim because it seems pretty niche.

[workingjubilee]

This flag has a very "from the days when there was an OABI" vibe to it.

[workingjubilee]

I think we should start by warning when this flag is used, maybe that will get someone to explain their hypothetical use-case that cannot possibly be replaced by the -Ctarget-feature route.

[RalfJung]

I think we should start by warning when this flag is used, maybe that will get someone to explain their hypothetical use-case that cannot possibly be replaced by the -Ctarget-feature route.

All right, I made #129897 do exactly that now.

[apiraino]

WG-prioritization assigning priority on Zulip.

Also, (related discussion).

@rustbot label -I-prioritize +P-medium

[skade]

On the Cortex-R52, the FPU is mandatory and if anyone wants compatibility with older soft-float code they can either use armv7r-none-eabi, or they can come and make a compelling case for the v8-R version (kernel developers? idk). I'm not minded to add it on a whim because it seems pretty niche.

A good soft/no-float story is highly desired by Rust for Linux (and other kernel developers): Rust-for-Linux/linux#514

There's the clippy lint to avoid floats, but it runs into the same issue as this flag: lints are crate per crate, while this should be binary by binary.

[RalfJung]

A good soft/no-float story is highly desired by Rust for Linux (and other kernel developers): Rust-for-Linux/linux#514

That will almost surely evolve around -Ctarget-feature=+soft-float, or some new way of exposing that target feature, not around -Csoft-float. The -C flag is mostly a red herring and confusing. See the discussion above for more details.