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.