Regression when using `linker=arm-none-eabi-gcc`

[adamgreig]

The cortex-m CI tests building with all our supported linkers: Rust's provided lld, ARM GCC's arm-none-eabi-ld, and ARM GCC's arm-none-eabi-gcc. It recently encountered an error when using arm-none-eabi-gcc in nightly builds since #112910.

The most likely culprit is that the failing version has started added "-fuse-ld=lld" to the linker arguments, which was not present in previous working versions. @lqd, I wonder if we're meant to be adding some other argument to disable adding -fuse-ld=lld?

Code

The error occurs with the cortex-m-rt CI and can be reproduced like so:

git clone https://github.com/rust-embedded/cortex-m
cd cortex-m/cortex-m-rt
rustup toolchain install nightly-2023-07-03
rustup target add thumbv6m-none-eabi --toolchain nightly-2023-07-03
cargo +nightly-2023-07-03 rustc --target thumbv6m-none-eabi --example alignment --features cortex-m/critical-section-single-core -- -C linker=arm-none-eabi-gcc -C link-arg=-nostartfiles

Or viewed in CI here.

The error is:

error: linking with `arm-none-eabi-gcc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="<snip>" VSLANG="1033" "arm-none-eabi-gcc" "/tmp/rustcFHUl0t/symbols.o" "/home/adam/Projects/re/cortex-m/target/thumbv6m-none-eabi/debug/examples/alignment-c363c9558a2fe06e.15yn3mrxz53m7uw7.rcgu.o" "/home/adam/Projects/re/cortex-m/target/thumbv6m-none-eabi/debug/examples/alignment-c363c9558a2fe06e.6wqau5vl49hu4fi.rcgu.o" "-Wl,--as-needed" "-L" "/home/adam/Projects/re/cortex-m/target/thumbv6m-none-eabi/debug/deps" "-L" "/home/adam/Projects/re/cortex-m/target/debug/deps" "-L" "/home/adam/Projects/re/cortex-m/target/thumbv6m-none-eabi/debug/build/cortex-m-rt-69b7ab10efe30aa1/out" "-L" "/home/adam/.rustup/toolchains/nightly-2023-07-03-x86_64-unknown-linux-gnu/lib/rustlib/thumbv6m-none-eabi/lib" "-Wl,-Bstatic" "/home/adam/Projects/re/cortex-m/target/thumbv6m-none-eabi/debug/deps/libpanic_halt-f60a67ec71296eeb.rlib" "/home/adam/Projects/re/cortex-m/target/thumbv6m-none-eabi/debug/deps/libcortex_m_rt-9a1a89eba3425cf7.rlib" "/home/adam/.rustup/toolchains/nightly-2023-07-03-x86_64-unknown-linux-gnu/lib/rustlib/thumbv6m-none-eabi/lib/librustc_std_workspace_core-cc16e9be0f247487.rlib" "/home/adam/.rustup/toolchains/nightly-2023-07-03-x86_64-unknown-linux-gnu/lib/rustlib/thumbv6m-none-eabi/lib/libcore-b9a65150d0351313.rlib" "/home/adam/.rustup/toolchains/nightly-2023-07-03-x86_64-unknown-linux-gnu/lib/rustlib/thumbv6m-none-eabi/lib/libcompiler_builtins-2769d4646d3d396e.rlib" "-Wl,-Bdynamic" "-fuse-ld=lld" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/home/adam/.rustup/toolchains/nightly-2023-07-03-x86_64-unknown-linux-gnu/lib/rustlib/thumbv6m-none-eabi/lib" "-o" "/home/adam/Projects/re/cortex-m/target/thumbv6m-none-eabi/debug/examples/alignment-c363c9558a2fe06e" "-Wl,--gc-sections" "-no-pie" "-nodefaultlibs" "-nostartfiles" "-Tlink.x"
  = note: collect2: fatal error: cannot find 'ld'
          compilation terminated.

Version it worked on

nightly-2023-07-02

Version with regression

nightly-2023-07-03

bisected to 8e2d5e3

from PR #112910

@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged

[jyn514]

rust/compiler/rustc_target/src/spec/thumb_base.rs

Line 37 in 993deaa

linker: Some("rust-lld".into()),

shows that the default for the target is rust-lld. i wonder if the new code uses the default instead of the linker in -C linker for some reason?

[lqd]

I wonder if we're meant to be adding some other argument to disable adding -fuse-ld=lld?

You were not meant to do anything, sorry about that. I'll fix it.

[lqd]

I can't build a thumbv6m-none-eabi toolchain locally, via ./x build library/ --target thumbv6m-none-eabi, which would be complete enough for this cortex-m test to build. There are issues about missing core/std.

I tried on a no_std example, and can also reproduce the arm-none-eabi-gcc issue and investigate more there, and that rust-lld and arm-none-eabi-ld work.

The code I added in #112910 is asked to add CLI arguments for a Gnu(Cc::Yes, Lld::Yes) flavor: this asks to link using lld via a c/c++ compiler, and why -fuse-ld=lld is added. I assume that flavor is incorrect when using -C linker=arm-none-eabi-gcc -C link-arg=-nostartfiles @adamgreig ? (I don't know who the target maintainers are, so I'll also ping the other 2 people involved in the discovery: @hannobraun @thejpster)

-C linker=arm-none-eabi-ld and -C linker=rust-lld still work because they result in a non-cc request, and we don't do anything there as expected.

For my own understanding: does arm-none-eabi-gcc use arm-none-eabi-ld by default maybe ? And if so, I'd expect that explicitly specifying the linker would also fix the issue, à la -C linker=arm-none-eabi-gcc -C link-arg=-nostartfiles -C link-arg=-fuse-ld=bfd which seems to work for me ?

I'll look into why this surprising flavor is used in this situation, as it seems to be the pre-existing issue here uncovered by the PR, and report back. It could be an issue in the flavor inference, or some information missing in the targets' definitions, and so on.