Hacker News Reader

Comment by karlding | Hacker News Reader

Out of curiosity, how is the embedded story (for both bare-metal and RTOS) in Rust nowadays? I took a look early last year, and I remember feeling that the ecosystem still wasn't as mature as I liked.

There's svd2rust [0] and dslite2svd [1], which is basically "bindgen for hardware". Please do correct me if I'm wrong, but from what I understood [2], most SVD files leave out a lot of information so a lot of what svd2rust generates is unsafe. Seems like the only way around that is to patch the SVD files. Is this still the case?

In addition, what about compiling with no stdlib? And how does that interop with existing Crates (ie. do new "embedded-specific" Crates need to be created?)

Super excited to see Rust gain traction! I'll definitely take another shot in my free time and see how the ecosystem has matured.

[0] https://github.com/japaric/svd2rust

[1] https://github.com/m-labs/dslite2svd

[2] https://www.reddit.com/r/rust/comments/687b3l/embedded_in_ru...

View on HN

I tried exploring no_std Rust recently, and found it to be quite frustrating. After just using a Result type I was getting errors of things like `eh_unwind_resume` being undefined. Toggling LTO rectified my problems but didn't give me much confidence in reliably using no_std

`-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`.

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