undefined symbol: __rustc::rust_begin_unwind when using panic="abort"

[alexandruradovici]

Starting with rust nightly from mid march, we get an undefined symbol: __rustc::rust_begin_unwind error when compiling no_std with panic="abort" targets. This happens for al least x86_64, armv6m and armv7m targets.

Example

We am trying to compile Tock's raspberry_pi_pico.

This is our rust-toolchain.toml file:

# Licensed under the Apache License, Version 2.0 or the MIT License.
# SPDX-License-Identifier: Apache-2.0 OR MIT
# Copyright Tock Contributors 2023.

[toolchain]
channel = "nightly-2025-04-15"
components = ["miri", "llvm-tools", "rust-src", "rustfmt", "clippy", "rust-analyzer"]
targets = ["thumbv6m-none-eabi", "thumbv7em-none-eabi", "thumbv7em-none-eabihf", "riscv32imc-unknown-none-elf", "riscv32imac-unknown-none-elf"]

This is the profile setup in Cargo.toml:

[profile.dev]
panic = "abort"
lto = true
opt-level = "z"
debug = true

[profile.release]
panic = "abort"
lto = true
opt-level = "z"
debug = true
codegen-units = 1

We expected it to successfully compile.

Instead, we get the undefined symbol error. It seems like the linker is ignoring the panic="abort" setting.

rustc --version --verbose:

rustc 1.88.0-nightly (2da29dbe8 2025-04-14)
binary: rustc
commit-hash: 2da29dbe8fe23df1c7c4ab1d8740ca3c32b15526
commit-date: 2025-04-14
host: aarch64-apple-darwin
release: 1.88.0-nightly
LLVM version: 20.1.2

The full error that I get is:

error: linking with `rust-lld` failed: exit status: 1
  |
  = note:  "rust-lld" "-flavor" "gnu" "/var/folders/c3/1cb2ssrx0s7_qdx3bxzmmhl40000gn/T/rustcpKJxGx/symbols.o" "<1 object files omitted>" "--as-needed" "-Bstatic" "/Users/alexandru/programe/tock/tock/target/thumbv6m-none-eabi/debug/deps/{libcompiler_builtins-0a2c747e19573fb9.rlib}.rlib" "-L" "/var/folders/c3/1cb2ssrx0s7_qdx3bxzmmhl40000gn/T/rustcpKJxGx/raw-dylibs" "-Bdynamic" "--eh-frame-hdr" "-z" "noexecstack" "-o" "/Users/alexandru/programe/tock/tock/target/thumbv6m-none-eabi/debug/deps/raspberry_pi_pico-dd9a9cab993fa2c5" "--gc-sections" "-nmagic" "-icf=all" "-L/Users/alexandru/programe/tock/tock/boards/build_scripts" "-L/Users/alexandru/programe/tock/tock/boards/raspberry_pi_pico" "-Tlayout.ld"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: rust-lld: error: undefined symbol: __rustc::rust_begin_unwind
          >>> referenced by panicking.rs:75 (src/panicking.rs:75)
          >>>               /Users/alexandru/programe/tock/tock/target/thumbv6m-none-eabi/debug/deps/raspberry_pi_pico-dd9a9cab993fa2c5.rp2040-5cdbd9b269ddca86.026to4zr8z5jaase0aj09ho26.0glt9gl.rcgu.o.1m3n085.rcgu.o:(core::panicking::panic_fmt)
          >>> referenced by panicking.rs:117 (src/panicking.rs:117)
          >>>               /Users/alexandru/programe/tock/tock/target/thumbv6m-none-eabi/debug/deps/raspberry_pi_pico-dd9a9cab993fa2c5.rp2040-5cdbd9b269ddca86.026to4zr8z5jaase0aj09ho26.0glt9gl.rcgu.o.1m3n085.rcgu.o:(core::panicking::panic_nounwind_fmt::runtime)
          

error: could not compile `raspberry_pi_pico` (bin "raspberry_pi_pico") due to 1 previous error

Working version

Everything compile fine when using rust nightly up to (including) this version:

rust-toolchain.toml:

# Licensed under the Apache License, Version 2.0 or the MIT License.
# SPDX-License-Identifier: Apache-2.0 OR MIT
# Copyright Tock Contributors 2023.

[toolchain]
channel = "nightly-2025-03-18"
components = ["miri", "llvm-tools", "rust-src", "rustfmt", "clippy", "rust-analyzer"]
targets = ["thumbv6m-none-eabi", "thumbv7em-none-eabi", "thumbv7em-none-eabihf", "riscv32imc-unknown-none-elf", "riscv32imac-unknown-none-elf"]

rustc --version --versbose:

rustc 1.87.0-nightly (43a2e9d2c 2025-03-17)
binary: rustc
commit-hash: 43a2e9d2c72db101f5fedac8b3acb78981b06bf2
commit-date: 2025-03-17
host: aarch64-apple-darwin
release: 1.87.0-nightly
LLVM version: 20.1.0

We get the error mentioned above if we try to compile with newer rust nightly versions.

[bjorn3]

The regression range coincides with #127173. Would you be able to check if that is indeed the regressing commit using https://github.com/rust-lang/cargo-bisect-rustc? Does it work with LTO disabled?

[bjorn3]

Actually, I think I know the problem already. Some of the examples use #[no_mangle] on the #[panic_handler]. It should work fine if you remove the #[no_mangle]. We should never have accepted #[no_mangle] on #[panic_handler] in the first place.

[alexandruradovici]

Yes, removing #[no_mangle] from the panic handler works.

[alexandruradovici]

Is this to be considered an error or at least a warning? I would could try adding a warning to the compiler or clippy, but I am n to sure if this is something that the project wants.

[bjorn3]

I agree we should make it an error. Likely will need to be a future incompat warning first.

[alexandruradovici]

Could you point me in the right direction on where to read about how to add this? I think I have a good idea where to add it and how to detect it (probably in check_attrs), but I am not sure how to issue the warning.

[bjorn3]

I think the most robust way to handle this would be to in the

rust/compiler/rustc_codegen_ssa/src/codegen_attrs.rs

Line 611 in 883f9f7

if let Some(link_name) = lang_item.link_name() {

if report a future incompat warning if codegen_fn_attrs.flags contains CodegenFnAttrFlags::NO_MANGLE and emit an error if it contains CodegenFnAttrFlags::RUSTC_STD_INTERNAL_SYMBOL (that one is unstable, so no need for a future incompat warning).

[alexandruradovici]

Thank you, I'll try to implement it.

The reason we used #[no_mangle] for the panic handler was to be able to add a breakpoint on it. Without this, is there any other reliable way to do that except:

#[no_mangle]
fn actual_panic_handler(p: &PanicInfo) -> ! {
  /* handle the panic */
}

#[panic_handler]
pub unsafe fn panic(p: &PanicInfo) -> ! {
  actual_panic_handler(p);
}

[bjorn3]

You can use rbreak rust_begin_unwind rather than break rust_begin_unwind. rbreak in gdb will set a breakpoint on any function matching the given regex (with .* prefix and postfix implied by default) Even with the new mangling rust_begin_unwind is still a substring of the symbol name.

[alexandruradovici]

I opened an PR with for this #140203 , any feedback would be greatly appreciated.