Add Rust std support for x86_64-unknown-uefi

[Ayush1325]

Notice

I have created a smaller PR (#105861) to get just a stripped-down version of std for UEFI merged. This would help simplify the review process and speed up the merge.

Introduction

Hello everyone, I have been working on porting Rust std to UEFI as a part of my Google Summer of Code 2022 project. While there are still problems left to fix, I would like to get more people experienced with Rust to check it out and provide feedback since this is my first time working with the Rust library internals.

Information about the current state of this implementation can be found at src/doc/rustc/src/platform-support/unknown-uefi.md. Some of the biggest limitations of the current implementation are the following:

1. The custom entry point function for UEFI is present at library/std/src/sys/uefi/mod.rs, This breaks using std with the no_main feature. Maybe this can be generated by the compiler like the C entry pointer, but not sure.: Now generated by compiler like C-main.

2. sys/uefi/net module was implemented only for running tests using remote-test-server and thus is not implemented for any actual production use. If someone really wants to implement it, it would be best to do it on top of SIMPLE_NETWORK_PROTOCOL, but that won't be possible in the GSoC timeframe.

3. No panic=unwind or backtrace support.

4. Pipes are basically a hack and should not be used unless someone knows what they are doing.: Using a dedicated Pipe Protocol now. However, this protocol hasen't been tested outside of src/tests/ui yet.

5. Feature panic_abort_tests is broken. While the UEFI stdio prints the correct output, capturing test output is not working with this feature.: Fixed

6. should_panic is broken for tests when panic_abort_tests is disabled.: Fixed

7. Command is kinda broken. The current spawn is blocking. More about this can be found here

Feel free to try it out and provide feedback. It is possible to run tests using remote-test-client and remote-test-server. For more details, you might want to look at my blog.

For those who are wondering how a target like UEFI can benefit from std support, here are a few examples:

1. Writing UEFI shell applications. This includes stuff like benchmarks, self-test utilities, etc. Many drivers should also be able to use std.
2. Finding UEFI target bugs. During this work, I have found 3 numeric tests that cause CPU exceptions for UEFI (they are fixed now. Also, I have found 2 additional bugs (which seem like bugs in llvm soft-float) which went unnoticed because there was no easy way to do any broad testing.
3. Provide a stable interface for library developers. The current std contains some functions under std::os::uefi::env to provide access to the underlying SystemTable and SystemHandle, which are essential for writing anything for UEFI.

Related Links

1. Tracking Issue
2. API Change Proposal

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @thomcc (or someone else) soon.

Please see the contribution instructions for more information.

[rust-highfive]

⚠️ Warning ⚠️

• These commits modify submodules.

[Ayush1325]

r? @dvdhrm

[joboet]

I think this is really cool! I played a bit with UEFI myself, and while I would definitely not use std for writing bootloaders (where you need very precise control over initialisation), having it available should be really helpful when writing UEFI applications.

A small nitpick: io::Error::new allocates even for static data, so it is better to use the internal io::error::const_io_error for these cases.

[Ayush1325]

I would like other people's opinions about adding UefiPrefix to std::path::Prefix. The reason this was added is that a file path on UEFI looks like the following:

{Volume Device Path}/\\{file path from root}

Thus I added UefiPrefix to represent the Volume Device Path as Prefix (Since it is similar to windows drives. Uefi Shell treats it like drives providing a shorthand to access them as well). However, seeing the CI, it might break quite a few crates, so maybe I should use one of the pre-existing enum variants and change the documentation?

[Dylan-DPC]

Closing this in favour of #105861