Can't set breakpoints on rust_panic.

[nical]

When debugging a rust program, it is very useful to be able to set breakpoints on rust_panic, however this stopped working at some point. gdb cannot find a rust_panic symbol to break on.
Using nm I can see that there is a symbol rust_panic.llvm.5A8AA348 in the debug binary I am currently looking at, with the 5A8AA348 part varying from computer to computer (I suppose it's related to the llvm or compiler version).

Setting a breakpoint on rust_panic.llvm.5A8AA348 works, but it's quite awful to have to look for symbols every time a panic needs to be investigated.

Tested with:

• rustc 1.23.0-nightly (827cb0d 2017-11-26)
• rustc 1.24.1 (d3ae9a9 2018-02-27)

Looks like it got fixed at some point before rustc 1.26.0-nightly (2789b06 2018-03-06), but it is currently broken on stable.

[nical]

Actually, rust_panic is still "mangled" in rustc stable 1.26.0.

[kvark]

Would be great to get this fixed!

[pnkfelix]

Odd, we have it marked as no_mangle here:

rust/src/libstd/panicking.rs

Lines 519 to 522 in 0b0d2ed

	/// A private no-mangle function on which to slap yer breakpoints.
	#[no_mangle]
	#[allow(private_no_mangle_fns)] // yes we get it, but we like breakpoints
	pub fn rust_panic(mut msg: &mut dyn BoxMeUp) -> ! {

[michaelwoerister]

This might be a side effect of ThinLTO which does some mangling of symbols. Maybe a \0 prefix in the LLVM name could help here? (see https://llvm.org/docs/LangRef.html#identifiers)

cc @alexcrichton

[alexcrichton]

Yes ThinLTO is what manufactures the rust_panic.llvm.5A8AA348 symbol and that's because it's not listed as #[inline(never)] I believe, I'll send a PR to fix that.

[alexcrichton]

#54590

[lu-zero]

rustc 1.31.0-nightly (2bd5993ca 2018-10-02) seem to still have the problem at least on Linux.

[kvark]

FWIW, I disagree with C-enhancement tag. This is clearly a bug from my perspective. Being able to easily break on panic is a must have experience.

[petrochenkov]

It also would be nice to make catch throw/catch catch work with panic/catch_unwind.
I'm not sure how exactly our panics differ from C++ exceptions, but the aforementioned commands don't catch them in gdb.
cc @tromey

[tromey]

catch throw and friends work by hooking in to the unwinder. The libstdc++ unwinder provides "sdt" probe points, but gdb will fall back to using the exported unwinder function names like __cxa_throw. Extending this to Rust should not be too difficult, provided that the names are stable. Another option is to follow the Ada lead and add rust-specific catch subcommands. Perhaps this could even be done in the Rust-supplied gdb scripts without modifying gdb.

There is also a probe point in the libgcc unwinder that is used to implement the "next over throw" feature. The idea is that if you next in gdb, a throw in the inferior should only cause a stop if it lands in the current frame or any older frame. If Rust is using the libgcc unwinder on Linux then this should probably already work. (I haven't tried it yet.)

Related is #21102. I tend to think the Rust gdb scripts should set a breakpoint on an aborting panic, by default, but not on an unwinding panic. I haven't looked into how to accomplish this.

[tromey]

This seems to be fixed. Using stable (1.43.1) I see rust_panic in a simple debug executable:\

000000000000c350 T rust_panic

[nical]

I can also see the symbol now.