Building std without support for certain lang items
AZMCode opened this issue · 2 comments
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
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 thepanic-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.
Thank you for the super detailed response. I see this issue is moot.
Closing.