Possible regression with rust_panic being mangled

[Qwinci]

I think this pr #127173 changed rust_panic to be mangled which breaks gdb breaking on it with rust_panic name. The comment in

rust/library/std/src/panicking.rs

Line 888 in e964cca

/// An unmangled function (through `rustc_std_internal_symbol`) on which to slap

says that it should be unmangled, likely #[no_mangle] should be added to it or stabilize some other name for it as else you have to rely on the internal mangled name __rustc::rust_panic in e.g. Intellij Rust plugin or other things that want to add a breakpoint to it.

[jieyouxu]

cc @bjorn3

[bjorn3]

You can use rbreak rust_panic (gdb) or b s -r rust_panic (lldb) instead. I intentionally changed rust_panic to be mangled to prevent conflicts when two staticlibs compiled by different rustc versions get linked into the same executable. Previously this would either give a linker error or a panic inside one of the staticlibs would call the rust_panic function of the other staticlib despite not being ABI compatible.

[Qwinci]

You can use rbreak rust_panic (gdb) or b s -r rust_panic (lldb) instead. I intentionally changed rust_panic to be mangled to prevent conflicts when two staticlibs compiled by different rustc versions get linked into the same executable. Previously this would either give a linker error or a panic inside one of the staticlibs would call the rust_panic function of the other staticlib despite not being ABI compatible.

Ah, Ill forward this info to the Intellij plugin team.

[bjorn3]

The comment should be updated though.

[Qwinci]

I tried breaking on it with rbreak rust_panic and it looks like it doesn't properly break on it and it also matches other functions than the rust_panic one (which I guess might not be an issue given they are all panic related).

(gdb) set breakpoint pending on
(gdb) rbreak rust_panic
Function "_RNvCskKhzHMMzY84_7___rustc20___rust_panic_cleanup" not defined in "/rustc/e9f8103f93f8ce2fa2c15c0c6796ec821f8ae15d/library/panic_unwind/src/lib.rs".
Breakpoint 1 (/rustc/e9f8103f93f8ce2fa2c15c0c6796ec821f8ae15d/library/panic_unwind/src/lib.rs:'_RNvCskKhzHMMzY84_7___rustc20___rust_panic_cleanup') pending.
fn panic_unwind::__rust_panic_cleanup();
Function "_RNvCskKhzHMMzY84_7___rustc10rust_panic" not defined in "/rustc/e9f8103f93f8ce2fa2c15c0c6796ec821f8ae15d/library/std/src/panicking.rs".
Breakpoint 2 (/rustc/e9f8103f93f8ce2fa2c15c0c6796ec821f8ae15d/library/std/src/panicking.rs:'_RNvCskKhzHMMzY84_7___rustc10rust_panic') pending.
fn std::panicking::rust_panic();
Function "_ZN3std9panicking20rust_panic_with_hook17h3be384070c17cbcbE" not defined in "/rustc/e9f8103f93f8ce2fa2c15c0c6796ec821f8ae15d/library/std/src/panicking.rs".
Breakpoint 3 (/rustc/e9f8103f93f8ce2fa2c15c0c6796ec821f8ae15d/library/std/src/panicking.rs:'_ZN3std9panicking20rust_panic_with_hook17h3be384070c17cbcbE') pending.
fn std::panicking::rust_panic_with_hook();
(gdb) run
Starting program: /home/visa/Projects/a/a/target/debug/a 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".

thread 'main' panicked at src/main.rs:2:5:
foo
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[Inferior 1 (process 32534) exited with code 0145]

[bjorn3]

I tried breaking on it with rbreak rust_panic and it looks like it doesn't properly break on it

I can reproduce this issue. For some reason the breakpoints remain pending and even if you set them while the program is running, it still says that the symbol is not defined.

and it also matches other functions than the rust_panic one (which I guess might not be an issue given they are all panic related).

rbreak __rust_start_panic would avoid that. This is the function that rust_panic calls.

[bjorn3]

I just tried using a gdb I built from the latest development version a week ago. It works just fine. So somewhere between gdb 13.1 and the latest development version this was fixed. I can't easily bisect it though.

[bjorn3]

https://gitlab.com/gnutools/binutils-gdb/-/commit/3d6744493634e704b6977924a0cc8082886523f5 fixed this. So gdb 16 and up works fine. Anything below that doesn't handle rbreak for rust programs correctly.