Undefined reference to _Unwind_Resume
#47493
Comments
|
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 |
|
Seems similar to #47442. As mentioned there, projects that don't want unwinding need to compile with panic=abort to work reliably. |
|
Neither setting panic=abort nor specifying the eh_personality, eh_unwind_resume, and panic_fmt lang_items successfully compile with debug settings for me |
|
Even when you recompile |
pietroalbini
added
A-LLVM
|
Might this be related with #47551? |
|
@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: If I add
Attempting to build against |
|
Ah, sorry, my analysis at the end there is bogus, the rust/src/librustc_trans/context.rs Lines 395 to 422 in da569fa |
|
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: The above fails to build with |
|
FWIW, when looking at the llvm-ir emitted for unwrap_failed, with opt-level=0, I can see multiple |
|
I looked into this a bit more since Rust 1.30 came out. I thought with the ability for stable Rust to allow let x = Some(5);
let y = x.unwrap();After a bit more reading on the undefined reference to Coming back to Rust, I believe the issue lies with the |
|
I suspect this is (loosely) similar to #55352 where Rustc creates landing pads for unwinding even if those pads are unreachable. A I doubt this is specifically related to mixing unwind implementations (the |
|
Same problem. this code works with |
|
Updated test case: #![no_std]
#![no_main]
#[panic_handler]
pub fn panic(_info: &core::panic::PanicInfo) -> ! {
loop {}
}
#[no_mangle]
pub extern "C" fn _start() -> ! {
let a: Result<(), usize> = Err(42);
a.unwrap();
loop {}
}Compile with
So there's still references to So, no explicit references to either function, presumably they are relocated in? So there's relocation instructions for both functions:
Performing code-flow analysis on the generated code shows that the relocation site for |
|
More analysis... looking at the LLVM-IR, same source code, new command ...
; core::result::Result<T,E>::unwrap
; Function Attrs: inlinehint nounwind nonlazybind
define internal void @"_ZN4core6result19Result$LT$T$C$E$GT$6unwrap17h1179f71b032e9d7eE"(i64, i64) unnamed_addr #0 personality i32 (...)* @rust_eh_personality {
start:
...
bb5: ; preds = %start
...
; invoke core::result::unwrap_failed
invoke void @_ZN4core6result13unwrap_failed17hfb1545ecedec37d1E([0 x i8]* noalias nonnull readonly align 1 bitcast (<{ [43 x i8] }>* @0 to [0 x i8]*), i64 43, {}* nonnull align 1 %22, [3 x i64]* noalias readonly align 8 dereferenceable(24) bitcast ({ void (i64*)*, i64, i64, i1 (i64*, %"core::fmt::Formatter"*)* }* @vtable.0 to [3 x i64]*))
to label %unreachable unwind label %cleanup
...So it seems that the I also tested with I'm not sure what the right answer is here, either require compiling ones own (non-unwinding) Edit - |
|
I hit this, too, with
|
|
a quickfix for now is to add |
- Did a final sweep in opte-drv to see if there was anything else to migrate over to xde. - Moved over the _Unwind_Resume hack. It seems xde has been working fine without it, but I also notice the Rust issue that originally prompted me to create this hack is still marked as open. So I thought it would be best to migrate the hack over to xde just as a safeguard against the problem coming back until that Rust issue is resolved. rust-lang/rust#47493
- Did a final sweep in opte-drv to see if there was anything else to migrate over to xde. - Moved over the _Unwind_Resume hack. It seems xde has been working fine without it, but I also notice the Rust issue that originally prompted me to create this hack is still marked as open. So I thought it would be best to migrate the hack over to xde just as a safeguard against the problem coming back until that Rust issue is resolved. rust-lang/rust#47493
- Did a final sweep in opte-drv to see if there was anything else to migrate over to xde. - Moved over the _Unwind_Resume hack. It seems xde has been working fine without it, but I also notice the Rust issue that originally prompted me to create this hack is still marked as open. So I thought it would be best to migrate the hack over to xde just as a safeguard against the problem coming back until that Rust issue is resolved. rust-lang/rust#47493
- Did a final sweep in opte-drv to see if there was anything else to migrate over to xde. - Moved over the _Unwind_Resume hack. It seems xde has been working fine without it, but I also notice the Rust issue that originally prompted me to create this hack is still marked as open. So I thought it would be best to migrate the hack over to xde just as a safeguard against the problem coming back until that Rust issue is resolved. rust-lang/rust#47493
on non-optimized builds we reference _Unwind_Resume; see rust-lang/rust#47493 enabling LTO is an easy workaround until a cleaner solution is available upstream
on non-optimized builds we reference _Unwind_Resume; see rust-lang/rust#47493
on non-optimized builds we reference _Unwind_Resume; see rust-lang/rust#47493
on non-optimized builds we reference _Unwind_Resume; see rust-lang/rust#47493
|
Just creating an |
I tried to compile a no_std project with Rust, but setting the
eh_unwind_resumelang_item does not seem to work properly. Building in release with cargo or -O with rustc works properly, but a debug build fails with anundefined reference to '_Unwind_Resume'.Here is the code I tried to get working.
rustc --version --verbose:
The text was updated successfully, but these errors were encountered: