Stripped executables don't print backtrace with RUST_BACKTRACE=1

[bjorn3]

I tried this code:

echo 'fn main() { panic!(); }' | rustc - -Cstrip=symbols
RUST_BACKTRACE=1 ./rust_out
RUST_BACKTRACE=full ./rust_out

I expected to see this happen: Both invocations of the executable show a backtrace.

Instead, this happened: RUST_BACKTRACE=1 results in an empty backtrace:

RUST_BACKTRACE=1 ./rust_out
thread 'main' panicked at <anon>:1:13:
explicit panic
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

While RUST_BACKTRACE=full does print a backtrace with addresses in the place of symbols:

RUST_BACKTRACE=full ./rust_out
thread 'main' panicked at <anon>:1:13:
explicit panic
stack backtrace:
   0:     0x5593502b9312 - <unknown>
   1:     0x5593502d4a93 - <unknown>
   2:     0x5593502b7023 - <unknown>
   3:     0x5593502b9162 - <unknown>
   4:     0x5593502ba203 - <unknown>
   5:     0x5593502b9fe5 - <unknown>
   6:     0x5593502babd5 - <unknown>
   7:     0x5593502baaac - <unknown>
   8:     0x5593502b9809 - <unknown>
   9:     0x5593502ba9c2 - <unknown>
  10:     0x559350298e3a - <unknown>
  11:     0x559350298dc3 - <unknown>
  12:     0x559350298da6 - <unknown>
  13:     0x559350298d89 - <unknown>
  14:     0x5593502b4f70 - <unknown>
  15:     0x559350298d71 - <unknown>
  16:     0x559350298e55 - <unknown>
  17:     0x7fe198532ca8 - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  18:     0x7fe198532d65 - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:360:3
  19:     0x559350298c81 - <unknown>
  20:                0x0 - <unknown>

This is probably because __rust_end_short_backtrace is matched by symbol name rather than by address causing the trimmed backtrace to never start. As solution we could either also check __rust_end_short_backtrace by address or if the backtrace is empty create a new backtrace but this time untrimmed.

Meta

rustc --version --verbose:

rustc 1.90.0 (1159e78c4 2025-09-14)
binary: rustc
commit-hash: 1159e78c4747b02ef996e55082b704c09b970588
commit-date: 2025-09-14
host: x86_64-unknown-linux-gnu
release: 1.90.0
LLVM version: 20.1.8

Backtrace

<backtrace>

[eggyal]

I have a fix for this that is matching the begin/end frames by their address rather than symbol name.

However there are a couple of existing UI tests, namely panics/short-ice-remove-middle-frames.rs and panics/short-ice-remove-middle-frames-2.rs, which exercise/test the stripping logic by injecting their own frames with similarly named functions. Obviously this works when matching by symbol name, but not when matching by address. It's also a pretty horrible hack (depending on implementation detail).

However, I can't see a good way to fix that without exposing the real begin/end functions from the standard library for the ui tests to use... is that an acceptable use of #[doc(hidden)] #[unstable(...)] pub fn in std?

[eggyal]

@rustbot claim

[eggyal]

Ah, I just realised that those tests exist because rustc is doing precisely the same to have ICE backtraces abbreviated. So it too would need to access such exposed functions from stdlib.

[eggyal]

And the rustc side is also a slight nuisance to fix because it'll need to wait for the stage0 to be bumped to include the new stdlib...