Hacker News Reader

Comment by red75prime | Hacker News Reader

`-C panic=abort` compiler option should have fixed the problem. If you want to be able to intercept panics, you need to provide implementations for `eh_unwind_resume` and `eh_personality`.

View on HN

Perhaps it's just an issue of me not being educated enough with this kind of low-level Rust. Setting panic to abort in the cargo config did indeed fix `eh_personality` being undefined, but `eh_unwind_resume` still seems finnicky. Building in release will work, but building in debug will still complain

I'm a little rusty on the topic, but it seems ([0]) that adding `#[no_mangle]` before `panic_fmt` should fix it.

[0] https://github.com/rust-lang/rust/issues/38281

Even specifying `eh_unwind_resume` as a lang item gives me a linking error in debug builds.

Did you define them exactly the same way? Every aspect has to be identical; extern, no mangle, function name, arguments, lang item.

If this happens to be open source, I can take a look at it.

I just whipped this up yesterday to test if I was still having the same issues. Debug fails to build with a linking error "undefined reference to `_Unwind_Resume`". Release build works fine.

I'm using rustc 1.25.0-nightly on Ubuntu 17.10

https://gist.github.com/jefftime/d7e96461138b5aa6895550b63ca...

The lang item symbol names need to be prefixed with rust_ like this: https://gist.github.com/steveklabnik/5abd59a8fe7e5abda3db58b...

This didn't fix the compilation errors for me. I can set my own no_mangle pub extern `_Unwind_Resume` function (without declaring it a lang_item) and fix the undefined reference that way, but I'm pretty sure that's not how one's supposed to solve this

Hm, it compiled for me. Well, it didn't know about the C functions that were being linked in, but it didn't complain about the lang items.

You should file a bug, maybe.

For low level code, do you really want to abort on panic? Rust error handling is easily my least favorite part of the language, combining the disadvantages of exceptions and return codes.

Many do, yes. Panics are non-recoverable errors, and aborting produces leaner code, which is important on embedded.

Panics are recoverable though

They’re not guaranteed to be, so you can’t rely on it. You can say that you do, but then you may cut yourself off from the rest of the ecosystem. Libraries generally can’t rely on either behavior, applications choose.

And that's why I think the Rust has a worst-of-both-worlds error handling strategy.

Reply on news.ycombinator.com