Regression: undefined symbol __atomic_load_4 on risvc32imac-unknown-none-elf
#85736
Comments
xobs
changed the title
rust-lld: error: undefined symbol: __atomic_load_4 on risvc32imac-unknown-none-elf__atomic_load_4 on risvc32imac-unknown-none-elf
jonas-schievink
added
O-riscv
rustbot
added
the
I-prioritize
rustbot
added
the
ICEBreaker-Cleanup-Crew
|
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good cc @AminArria @camelid @chrissimpkins @contrun @DutchGhost @elshize @h-michael @HallerPatrick @hdhoang @hellow554 @henryboisdequin @imtsuki @JamesPatrickGill @kanru @KarlK90 @LeSeulArtichaut @MAdrianMattocks @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @shekohex @sinato @smmalis37 @steffahn @Stupremee @tamuhey @turboladen @woshilapin @yerke |
|
So this appears to be triggered by the I created a repro at https://github.com/xobs/rust-1.52.1-link-error but I couldn't get the repro any smaller. When I tried, the problem went away. This is demonstrated by using the My guess is that the function is getting large enough that it is... doing something. Even though the two calls are identical. |
|
Repro: build as a binary crate with #![no_std]
#![no_main]
use core::sync::atomic::{Ordering, AtomicUsize};
#[panic_handler]
fn handle_panic(_arg: &core::panic::PanicInfo) -> ! {
loop {}
}
#[no_mangle]
pub extern "C" fn _start() -> ! {
let x = AtomicUsize::new(0);
x.load(Ordering::SeqCst);
loop { }
}searched nightlies: from nightly-2021-02-05 to nightly-2021-05-04 bisected with cargo-bisect-rustc v0.6.0Host triple: x86_64-unknown-linux-gnu cargo bisect-rustc --target=riscv32imac-unknown-none-elf --preserve --start=2021-02-05 --end=2021-05-04 -- rustc -- -C linker-plugin-lto=yes --target=riscv32imac-unknown-none-elf |
|
Assigning priority as discussed in the Zulip thread of the Prioritization Working Group. @rustbot label -I-prioritize +P-medium +I-nominated |
rustbot
added
P-medium
This roughly reverts PR rust-lang#66548 Atomic "CAS" are still disabled for targets without the *“A” Standard Extension for Atomic Instructions*. However this extension only adds instructions for operations more complex than simple loads and stores, which are always atomic when aligned. In the [Unprivileged Spec v. 20191213](https://riscv.org/technical/specifications/) section 2.6 *Load and Store Instructions* of chapter 2 *RV32I Base Integer Instruction Set* (emphasis mine): > Even when misaligned loads and stores complete successfully, > these accesses might run extremely slowly depending on the implementation > (e.g., when implemented via an invisible trap). Further-more, whereas > **naturally aligned loads and stores are guaranteed to execute atomically**, > misaligned loads and stores might not, and hence require > additional synchronization to ensure atomicity. Unfortunately PR rust-lang#66548 did not provide much details on the bug that motivated it, but rust-lang#66240 and rust-lang#85736 appear related and happen with targets that do have the A extension.
Re-enable atomic loads and stores for all RISC-V targets This roughly reverts PR rust-lang#66548 Atomic "CAS" are still disabled for targets without the *“A” Standard Extension for Atomic Instructions*. However this extension only adds instructions for operations more complex than simple loads and stores, which are always atomic when aligned. In the [Unprivileged Spec v. 20191213](https://riscv.org/technical/specifications/) section 2.6 *Load and Store Instructions* of chapter 2 *RV32I Base Integer Instruction Set* (emphasis mine): > Even when misaligned loads and stores complete successfully, these accesses might run extremely slowly depending on the implementation (e.g., when implemented via an invisible trap). Further-more, whereas **naturally aligned loads and stores are guaranteed to execute atomically**, misaligned loads and stores might not, and hence require additional synchronization to ensure atomicity. Unfortunately PR rust-lang#66548 did not provide much details on the bug that motivated it, but rust-lang#66240 and rust-lang#85736 appear related and happen with targets that do have the A extension.
|
Seems to be working with rustc 1.75.0-nightly (249624b 2023-10-20). |
|
@xobs is this still a problem for you, with current rustc? |
|
I haven't seen this problem in a while. Closing. Thank you for the fix! |
|
We just had a user report an issue with Rust 1.75.0 today that was solved by changing LTO from "fat" to "thin", so this appears to still exist. The error in question is: Changing |
|
This looks a bit different, this time it's not about @xobs could you please provide a minimal example that reproduces this issue? I.e. code and cargo and target configuration you're using, as well as the compiler invocation? |
Description
When building for
riscv32imac-unknown-none-elf,rustcis occasionally generating calls to__atomic_load_4. This symbol doesn't appear to exist, even though atomics are supported on this platform. Furthermore, I'm not sure if atomics are used anywhere in this codepath --logis the only crate in the dependency tree that I haven't verified.This works fine if I target
riscv32i-unknown-none-elf, which disables atomic generation.Furthermore, this builds fine if I use rustc
1.51, however it fails with rustc1.52.1.Background
I'm trying to work with the crate
gdbstubto integrate it into a kernel running on baremetal RISC-V. The target isriscv32imac-unknown-none-elf, which has atomics. For some reason, the compiler is generating calls to__atomic_load_4, which doesn't exist.Meta
rustc --version --verbose:rustc 1.51
rustc 1.52.1
The text was updated successfully, but these errors were encountered: