🐛 Symbol multiply defined since nightly-2023-12-02 with custom builtins.

[ithinuel]

cargo build --release fails when building an rp2040 application with lto=fat.

Code

To reproduce:

git clone https://github.com/ithinuel/sandbox-rp2040 -b rust-regression

cd sandbox-rp2040
cargo build --release

I expected to see the project build successfully.

Instead, it fails with:

warning: Linking globals named '__addsf3': symbol multiply defined!

error: failed to load bitcode of module "rp2040_hal-99af59d59c714fe0.rp2040_hal.6c650a4395998581-cgu.0.rcgu.o": 

warning: `rust-regression` (bin "rust-regression") generated 1 warning
error: could not compile `rust-regression` (bin "rust-regression") due to 1 previous error; 1 warning emitted

bisect-rustc

searched nightlies: from nightly-2023-12-01 to nightly-2023-12-03
regressed nightly: nightly-2023-12-02
searched commit range: 87e1447...8c2b577
regressed commit: 8c2b577

bisected with cargo-bisect-rustc v0.6.7

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

cargo bisect-rustc --start=2023-12-01 --end=2023-12-03 -vv --target thumbv6m-none-eabi -- build --release 

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

Background

The rp2040 mcu has in-ROM implementation of some builtins. The rp2040-hal implements the necessary magic in order to use these rather than the regular compiler-builtins that would otherwise consume flash are induce unecessary execution latency.
See here for memcpy, memset (and a few other) and here for float related builtins.

Such magic can be disabled with --features disable-intrinsics which allows to build on nightly-2023-12-02 at the cost of flash storage & execution speed.

initial report

• Bare template crashes during release build with lto = 'fat' in nightly rp-rs/rp2040-project-template#71

[ithinuel]

cc @dianqk working on another regression by the same commit:

• Windows x64 no-std build broken with errors related to compiler-builtins #118559
• Restore #![no_builtins] crates participation in LTO. #113923

[Dirbaio]

I'm not sure if this is a Rust bug, I don't think defining the builtins from a user crate like that was ever allowed. It was already broken before with build-std + lto=fat.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@ithinuel Would it be possible to reduce the sample code provided and include more debug information about the linking issue? Just as an additional help figuring out this issue. Thanks.

@rustbot label -I-prioritize +P-high +E-needs-mcve

[dianqk]

I'm not sure if this is a Rust bug, I don't think defining the builtins from a user crate like that was ever allowed. It was already broken before with build-std + lto=fat.

In fact, compiler-builtins provide customization options through weak linkage at https://github.com/rust-lang/compiler-builtins/blob/2731a4837bfe091a0ba3e449e3ebeff73a6d2562/Cargo.toml#L69-L78.

I tried it but I got a new error:

warning: __aeabi_uidiv changed binding to STB_WEAK
error: symbol '__aeabi_uidiv' is already defined
warning: __aeabi_idiv changed binding to STB_WEAK
error: symbol '__aeabi_idiv' is already defined

I am investigating this issue while looking for a suitable solution. LLVM provides a symbol override method for linking IRs, which is one possible way.

@rustbot label +A-linkage
@rustbot claim