Undefined reference to `_Unwind_Resume`

[jefftime]

I tried to compile a no_std project with Rust, but setting the eh_unwind_resume lang_item does not seem to work properly. Building in release with cargo or -O with rustc works properly, but a debug build fails with an undefined reference to '_Unwind_Resume'.

Here is the code I tried to get working.

rustc --version --verbose:

rustc 1.25.0-nightly (e6072a7b3 2018-01-13)
binary: rustc
commit-hash: e6072a7b3835f1875e81c9fd27799f9b20a0770c
commit-date: 2018-01-13
host: x86_64-unknown-linux-gnu
release: 1.25.0-nightly
LLVM version: 4.0

[steveklabnik]

We had talked on Hacker News, and while this version compiles for me, it doesn't seem to for @jefftime

https://gist.github.com/steveklabnik/5abd59a8fe7e5abda3db58bd8c208fbb

[hanna-kruppe]

Seems similar to #47442. As mentioned there, projects that don't want unwinding need to compile with panic=abort to work reliably.

[jefftime]

Neither setting panic=abort nor specifying the eh_personality, eh_unwind_resume, and panic_fmt lang_items successfully compile with debug settings for me

[FenrirWolf]

Even when you recompile core via xargo?

[emilyalbini]

Might this be related with #47551?

[bossmc]

@pietroalbini Probably not, in that case the link is fine, but the generated binary is broken.

This also fails to link for me (rustc 1.25.0-nightly (79a521b 2018-01-15)) with:

Error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/andy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "test.test0.rcgu.o" "test.test1.rcgu.o" "test.test2.rcgu.o" "-o" "test" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-L" "/home/andy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-l" "c" "-Wl,-Bstatic" "/home/andy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-9d4b7130b0117f1c.rlib" "-Wl,-Bdynamic"
  = note: test.test0.rcgu.o: In function `_$LT$core..result..Result$LT$T$C$$u20$E$GT$$GT$::unwrap::h4cfe66017ee4cfbf':
          test0-317d481089b8c8fe83113de504472633.rs:(.text._ZN47_$LT$core..result..Result$LT$T$C$$u20$E$GT$$GT$6unwrap17h4cfe66017ee4cfbfE+0x3d): undefined reference to `_Unwind_Resume'
          test.test0.rcgu.o: In function `core::result::unwrap_failed::h8821e290e357350d':
          test0-317d481089b8c8fe83113de504472633.rs:(.text._ZN4core6result13unwrap_failed17h8821e290e357350dE+0x95): undefined reference to `_Unwind_Resume'
          collect2: error: ld returned 1 exit status

If I add -l gcc_s (since the glibc unwinding implementation is in libgcc_s) to the link command it links and runs correctly. Either:

• Result's [no_std] implementation is wrong to assume libgcc_s will be present to provide unwinding support
• The [no_std] link commands are wrong to not include libgcc_s on the XXX-unknown-linux-gnu target

Attempting to build against x86_64-unknown-linux-musl suggests it's the former, that build also fails with a much longer link failure (longer, but still all about _Unwind_XXX functions).

[bossmc]

Ah, sorry, my analysis at the end there is bogus, the #[lang = "eh_unwind_resume"] function is supposed to be used in place of the "default" implementation (which is just extern-ing a rust_eh_unwind_resume). See

rust/src/librustc_trans/context.rs

Lines 395 to 422 in da569fa

	pub fn eh_unwind_resume(&self) -> ValueRef {
	use attributes;
	let unwresume = &self.eh_unwind_resume;
	if let Some(llfn) = unwresume.get() {
	return llfn;
	}
	let tcx = self.tcx;
	assert!(self.sess().target.target.options.custom_unwind_resume);
	if let Some(def_id) = tcx.lang_items().eh_unwind_resume() {
	let llfn = callee::resolve_and_get_fn(self, def_id, tcx.intern_substs(&[]));
	unwresume.set(Some(llfn));
	return llfn;
	}
	let ty = tcx.mk_fn_ptr(ty::Binder(tcx.mk_fn_sig(
	iter::once(tcx.mk_mut_ptr(tcx.types.u8)),
	tcx.types.never,
	false,
	hir::Unsafety::Unsafe,
	Abi::C
	)));
	let llfn = declare::declare_fn(self, "rust_eh_unwind_resume", ty);
	attributes::unwind(llfn, true);
	unwresume.set(Some(llfn));
	llfn
	}

.

[glandium]

Today I've hit the same error with the following:

#![no_std]
#![no_main]
#![feature(lang_items)]
#[link(name="c")]
extern "C" {}

#[lang = "panic_fmt"]
#[no_mangle]
pub fn panic_fmt(_: core::fmt::Arguments, _: &'static str, _: u32, _: u32) -> ! {
    loop {}
}

#[no_mangle]
pub extern "C" fn main(_argc: isize, _arg: *const *const u8) -> isize {
    let a: Result<(), usize> = Err(42);
    a.unwrap();
    0
}

And with the following added to the corresponding Cargo.toml:

[profile.release]
panic="abort"

[profile.dev]
panic="abort"

The above fails to build with cargo +nightly build but builds fine with cargo +nightly build --release. x86_64-unknown-linux-gnu target.

[glandium]

FWIW, when looking at the llvm-ir emitted for unwrap_failed, with opt-level=0, I can see multiple to label %somelabel unwind label %cleanup, but there are none with opt-level=1. They seem to correspond to the assembly calling _Unwind_Resume.

[hadronized]

Hello. I have a similar issue there.

Code here.

[jefftime]

I looked into this a bit more since Rust 1.30 came out. I thought with the ability for stable Rust to allow [no_std] executables that this issue would be fixed. However, it still persists with a simple call to something like:

let x = Some(5);
let y = x.unwrap();

After a bit more reading on the undefined reference to _Unwind_Resume, I found out that this seems to be an issue with C++ applications when two or more objects files have been compiled with different versions of g++ and are trying to be linked. g++ has different stack unwinding methods depending on how it was compiled, and the linker has trouble in situations where object files differ in how they unwind the stack.

Coming back to Rust, I believe the issue lies with the panic = "abort" in Cargo.toml. I don't know enough about C++ or g++ stack unwinding to really say, but my guess is that by changing the panic handling method on Linux, the Rust object code has problems being linked with system libraries because there's a mismatch in stack unwinding. I'm not sure if this bug is applicable to Rust anymore. It might just be a side effect of trying to use [no_std] Rust executables that link with the C standard library.

[bossmc]

I suspect this is (loosely) similar to #55352 where Rustc creates landing pads for unwinding even if those pads are unreachable. A --release build will strip these (since they are unreachable) but a --debug build will not. If those landing pads are explicitly calling _Unwind_Resume rather than eh_unwind_resume (or similar) that would lead to this issue for debug builds.

I doubt this is specifically related to mixing unwind implementations (the .eh_frames section allows separate translation modules to use different unwind strategies, though there might be an issue if multiple of them are expecting to use different implementations with the same name...).