Linking MSP430 Code fails with unrecognized option '-znoexecstack'

[cr1901]

cargo-bisect-rustc Output

searched nightlies: from nightly-2021-04-19 to nightly-2021-06-01
regressed nightly: nightly-2021-05-23
searched commits: from 5dc8789 to e4ca166
regressed commit: 21e1cd9

bisected with cargo-bisect-rustc v0.6.0

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --preserve-target --preserve --start=2021-04-19 --end=2021-06-01 --with-src -v

Instructions

1. Make sure cargo-bisect-rustc, and optionally just are installed.
2. git clone https://github.com/cr1901/msp430-size. Use commit 51af8f8 specifically.
3. Invoke cargo-bisect-rustc --script=./test-noexec.sh --preserve-target --preserve --start=2021-04-19 --end=2021-06-01 --with-src -v. The bisector will use test-noexec.sh to look for whether compiling msp430 code succeeds or fails.

Error

On recent nightlies, msp430 linking using Rust will fail with something like this:

Compiling take-api v0.1.0 (/home/william/Projects/embedded/msp430/msp430-size/take-api)error: linking with `msp430-elf-gcc` failed: exit status: 1
  |
  = note: "msp430-elf-gcc" "-Wl,-znoexecstack" "-Wl,--as-needed" "-L" "/home/william/.rustup/toolchains/bisector-nightly-2021-05-23-x86_64-unknown-linux-gnu/lib/rustlib/msp430-none-elf/lib" "/home/william/Projects/embedded/msp430/msp430-size/target-bisector-nightly-2021-05-23-x86_64-unknown-linux-gnu/msp430-none-elf/release/examples/min-cda63f9889c5937a.min.4jvsmr96-cgu.0.rcgu.o" "-o" "/home/william/Projects/embedded/msp430/msp430-size/target-bisector-nightly-2021-05-23-x86_64-unknown-linux-gnu/msp430-none-elf/release/examples/min-cda63f9889c5937a" "-Wl,--gc-sections" "-no-pie" "-nodefaultlibs" "-L" "/home/william/Projects/embedded/msp430/msp430-size/target-bisector-nightly-2021-05-23-x86_64-unknown-linux-gnu/msp430-none-elf/release/deps" "-L" "/home/william/Projects/embedded/msp430/msp430-size/target-bisector-nightly-2021-05-23-x86_64-unknown-linux-gnu/release/deps" "-L" "/home/william/Projects/embedded/msp430/msp430-size/target-bisector-nightly-2021-05-23-x86_64-unknown-linux-gnu/msp430-none-elf/release/build/msp430-rt-adad60a0e1cd156f/out" "-L" "/home/william/Projects/embedded/msp430/msp430-size/target-bisector-nightly-2021-05-23-x86_64-unknown-linux-gnu/msp430-none-elf/release/build/msp430g2553-e7917708540bbd5f/out" "-L" "/home/william/.rustup/toolchains/bisector-nightly-2021-05-23-x86_64-unknown-linux-gnu/lib/rustlib/msp430-none-elf/lib" "-Wl,-Bstatic" "/tmp/rustcGX8Ln9/libmsp430_rt-734159736d6268eb.rlib" "-Wl,--start-group" "-Wl,--end-group" "/home/william/Projects/embedded/msp430/msp430-size/target-bisector-nightly-2021-05-23-x86_64-unknown-linux-gnu/msp430-none-elf/release/deps/libcompiler_builtins-73a9b2f3ac812575.rlib" "-Tlink.x" "-nostartfiles" "-mcpu=msp430" "-lmul_none" "-lgcc" "-Wl,-Bdynamic"
  = note: /home/william/.local/bin/../lib/gcc/msp430-elf/9.2.0/../../../../msp430-elf/bin/ld: unrecognized option '-znoexecstack'
          /home/william/.local/bin/../lib/gcc/msp430-elf/9.2.0/../../../../msp430-elf/bin/ld: use the --help option for usage information
          collect2: error: ld returned 1 exit status


error: aborting due to previous error

error: could not compile `take-api`

To learn more, run the command again with --verbose.

When #85531 was merged, the default value for linker_is_gnu option changed from false to true. msp430 appears to have not been changed by #85531, so linker_is_gnu is now set for msp430. If linker_is_gnu is set, Rust unconditionally adds -znoexecstack to the linker options, which msp430 doesn't support. But technically, the msp430 backend does use the GNU linker.

This is a bit of a bikeshed, but: I could set linker_is_gnu back to false with a comment, or perhaps special case the logic to add the -znoexecstack option? Does linker_is_gnu mean only "uses the GNU linker", or does it mean "uses the GNU linker plus specific options"? Thus, I'm opening an issue for possible feedback before fixing.

Other Context

Inline contents of test_noexec.sh

#!/bin/sh
cargo build --manifest-path=take-api/Cargo.toml --release --target=msp430-none-elf -Z build-std=core --example min

[apiraino]

Thanks @cr1901 for the great writeup and context.
cc: @luqmana since author of the PR: any insights to share on this?

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-medium

[luqmana]

Ooof, the linker errors strike again. In the short term, you could make the msp430 target explicitly set linker_is_gnu: false.

In the longer term, we really need a better way of encoding all these linker capabilities :/ You're right, linker_is_gnu is pretty under-speced currently. Ideally I think I would instead replace it with a number of more specific flags for each specific feature we need.