undefined reference to `__aeabi_unwind_cpp_pr0` on `arm-unknown-linux-gnueabihf` with `no_std` and `-Cforce-unwind-tables=yes`

For the target arm-unknown-linux-gnueabihf, compiling a simple no_std program with -Cforce-unwind-tables=yes fails to link with "undefined reference to __aeabi_unwind_cpp_pr0". With -Cforce-unwind-tables=noe compilation and linking succeeds.

bors discovered this in https://github.com/rust-lang/rust/pull/143613. I am mainly reporting it so I have an issue to reference in a FIXME I will add to that PR.

Step-by-step:

Here is how to reproduce with nightly-2025-09-23 and tests/ui/no_std/simple-runs.rs.

docker run -it ubuntu:24.04

apt update && apt install -y \
    g++-arm-linux-gnueabihf \
    libc6-dev-armhf-cross \
    curl

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- \
    --default-toolchain nightly-2025-09-23 \
    --target arm-unknown-linux-gnueabihf \
    -y

. "$HOME/.cargo/env"

curl -L https://raw.githubusercontent.com/rust-lang/rust/40560823602064/tests/ui/no_std/simple-runs.rs |
    rustc - \
        --target=arm-unknown-linux-gnueabihf \
        -Clinker=arm-linux-gnueabihf-gcc \
        -Cforce-unwind-tables=yes

Expected outcome

Compilation and linking succeeds.

Actual outcome

error: linking with `arm-linux-gnueabihf-gcc` failed: exit status: 1
          /usr/lib/gcc-cross/arm-linux-gnueabihf/13/../../../../arm-linux-gnueabihf/bin/ld: \
            rust_out.rust_out.afd78cf1fc8ce159-cgu.0.rcgu.o:(.ARM.exidx.text.main+0x0): \
            undefined reference to `__aeabi_unwind_cpp_pr0'
          collect2: error: ld returned 1 exit status

More details

This is most likely an LLVM bug because if you build with --emit=llvm-ir the .ll output does not contain any reference to the missing symbol, but after llc it is added.

$ cat simple-runs.simple_runs.276f170ea64f04-cgu.0.rcgu.ll

; ModuleID = 'simple_runs.276f170ea64f04-cgu.0'
source_filename = "simple_runs.276f170ea64f04-cgu.0"
target datalayout = "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "arm-unknown-linux-gnueabihf"

; __rustc::rust_begin_unwind
; Function Attrs: noreturn nounwind uwtable
define hidden void @_RNvCs65g1hH7WZMC_7___rustc17rust_begin_unwind(ptr align 4 %_info) unnamed_addr #0 {
start:
  br label %bb1

bb1:                                              ; preds = %bb1, %start
  br label %bb1
}

; Function Attrs: nounwind uwtable
define dso_local i32 @main(i32 %_argc, ptr %_argv) unnamed_addr #1 {
start:
  ret i32 0
}

; Function Attrs: nounwind uwtable
define hidden i32 @rust_eh_personality(i32 %_version, i32 %_actions, i64 %_exception_class, ptr %_exception_object, ptr %_context) unnamed_addr #1 {
start:
  br label %bb1

bb1:                                              ; preds = %bb1, %start
  br label %bb1
}

attributes #0 = { noreturn nounwind uwtable "target-cpu"="generic" "target-features"="+strict-align,+v6,+vfp2,-d32" }
attributes #1 = { nounwind uwtable "target-cpu"="generic" "target-features"="+strict-align,+v6,+vfp2,-d32" }

!llvm.module.flags = !{!0, !1}
!llvm.ident = !{!2}

!0 = !{i32 8, !"PIC Level", i32 2}
!1 = !{i32 7, !"PIE Level", i32 2}
!2 = !{!"rustc version 1.91.0-nightly (9c27f27ea 2025-09-08)"}

$ llc -filetype=obj simple-runs.simple_runs.276f170ea64f04-cgu.0.rcgu.ll -o simple.o
$ arm-linux-gnueabihf-objdump -x simple.o
SYMBOL TABLE:
00000000 l    df *ABS*  00000000 simple_runs.276f170ea64f04-cgu.0
00000000 l    d  .text  00000000 .text
00000000 g     F .text  00000004 .hidden _RNvCs65g1hH7WZMC_7___rustc17rust_begin_unwind
00000000         *UND*  00000000 __aeabi_unwind_cpp_pr0
00000004 g     F .text  00000008 main
0000000c g     F .text  00000004 .hidden rust_eh_personality

I believe the upstream bugs are https://github.com/llvm/llvm-project/issues/69020 and/or https://github.com/llvm/llvm-project/issues/26239.

Start with tests/ui/no_std/simple-runs.rs and reproduce the documented Docker command for the arm-unknown-linux-gnueabihf target with -Cforce-unwind-tables=yes. Compare the emitted LLVM IR with the object produced by llc, then determine whether a Rust-side regression test or change is appropriate; done means the failure is resolved or its upstream LLVM dependency is clearly tracked.