You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been messing around with #[no_std] programming, and specifically I've been dipping my toes into programming for the x86_64-unknown-uefi target.
Immediately thinking of error handling, I tried to use the thiserror crate, but remembered that the Error trait is defined in the standard library. This led me to tinkering around, and realizing that many traits and structs pertaining to the standard library could be implemented in my target platform. Specifically, the uefi crate provides an allocator, and an entrypoint macro and procedures. In fact, it even provides the panic-impl lang item, which is actually where my troubles start.
Upon attempting to compile my crate with std, I found that the only error reported at the moment was the fact that there was a duplicate implementation of the panic-impl lang item, one in std, and another in uefi.
While this may be misguided, and I'm open to correction in the case it is, I think it might be useful to put the panic implementation in the standard library behind a default feature. Would this be possible?
Apart from that, while this secondary question might be better asked in a separate issue, would specifying a custom path for the std sources be possible otherwise? If asked for I'll open a separate issue, but I'll keep the requests few for now.
The text was updated successfully, but these errors were encountered:
the Error trait is defined in the standard library
Just FYI: There is ongoing work to move the Error trait into core, which will make it available to no_std crates. See rust-lang/project-error-handling#3 for details.
the uefi crate provides an allocator, and an entrypoint macro and procedures. In fact, it even provides the panic-impl lang item, which is actually where my troubles start.
Only the uefi-services crate provides a panic handler. If you want to define the handler yourself or use a handler provided by a different crate, you can use the uefi crate directly. It has some optional cargo features to turn on allocator support if you like.
I think it might be useful to put the panic implementation in the standard library behind a default feature. Would this be possible?
The standard library already provides the panic::set_hook function to run custom code on panic, so you typically don't need to override the complete panic handler. Also, many types and functions of the standard library depend on unwinding, which would no longer work with a custom panic handler. So I'm not sure if swapping out the panic handler in the standard library would be a good idea.
There is some related discussion in #29. For the general idea of making the standard library configurable through cargo features, see #4.
would specifying a custom path for the std sources be possible otherwise?
As far as I know, this is not yet possible with -Zbuild-std. See #7.
I've been messing around with
#[no_std]
programming, and specifically I've been dipping my toes into programming for thex86_64-unknown-uefi
target.Immediately thinking of error handling, I tried to use the
thiserror
crate, but remembered that theError
trait is defined in the standard library. This led me to tinkering around, and realizing that many traits and structs pertaining to the standard library could be implemented in my target platform. Specifically, theuefi
crate provides an allocator, and an entrypoint macro and procedures. In fact, it even provides thepanic-impl
lang item, which is actually where my troubles start.Upon attempting to compile my crate with
std
, I found that the only error reported at the moment was the fact that there was a duplicate implementation of thepanic-impl
lang item, one instd
, and another inuefi
.While this may be misguided, and I'm open to correction in the case it is, I think it might be useful to put the panic implementation in the standard library behind a default feature. Would this be possible?
Apart from that, while this secondary question might be better asked in a separate issue, would specifying a custom path for the
std
sources be possible otherwise? If asked for I'll open a separate issue, but I'll keep the requests few for now.The text was updated successfully, but these errors were encountered: