Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Rust std support for x86_64-unknown-uefi #100316

Closed
wants to merge 60 commits into from

Conversation

Ayush1325
Copy link
Contributor

@Ayush1325 Ayush1325 commented Aug 9, 2022

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
Copy link
Collaborator

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.

@rustbot rustbot added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 9, 2022
@rust-highfive
Copy link
Collaborator

⚠️ Warning ⚠️

  • These commits modify submodules.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 9, 2022
@Ayush1325
Copy link
Contributor Author

r? @dvdhrm

Copy link
Member

@joboet joboet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

library/std/src/sys_common/ucs2.rs Outdated Show resolved Hide resolved
library/std/src/sys_common/ucs2.rs Outdated Show resolved Hide resolved
library/std/src/sys/uefi/stdio.rs Outdated Show resolved Hide resolved
library/std/src/sys/uefi/os_str.rs Outdated Show resolved Hide resolved
@Ayush1325 Ayush1325 force-pushed the uefi-master branch 4 times, most recently from 96e5d0b to ccc4443 Compare August 10, 2022 16:59
Cargo.lock Outdated Show resolved Hide resolved
@rust-log-analyzer

This comment has been minimized.

@Ayush1325
Copy link
Contributor Author

Ayush1325 commented Aug 11, 2022

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?

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@Ayush1325 Ayush1325 requested review from klensy, joboet and bjorn3 and removed request for klensy and joboet August 13, 2022 14:17
thomcc pushed a commit to tcdi/postgrestd that referenced this pull request Feb 10, 2023
This was originally a part of rust-lang/rust#100316.
However, extracting it to a seperate PR should help with any extra
testing that might be needed.

Signed-off-by: Ayush Singh <[email protected]>
thomcc pushed a commit to tcdi/postgrestd that referenced this pull request Feb 10, 2023
Update compiler-builtins

This was originally a part of rust-lang/rust#100316. However, extracting it to a seperate PR should help with any extra testing that might be needed.

Signed-off-by: Ayush Singh <[email protected]>
thomcc pushed a commit to tcdi/postgrestd that referenced this pull request Feb 10, 2023
This commit extracts WStrUnits from sys::windows::args to sys_common::wstr. This
allows using the same structure for other targets which use wtf8 (example UEFI).

This was originally a part of rust-lang/rust#100316

Signed-off-by: Ayush Singh <[email protected]>
thomcc pushed a commit to tcdi/postgrestd that referenced this pull request Feb 10, 2023
  Extract WStrUnits to sys_common::wstr

This commit extracts WStrUnits from sys::windows::args to sys_common::wstr. This allows using the same structure for other targets which use wtf8 (example UEFI).

This was originally a part of rust-lang/rust#100316

Signed-off-by: Ayush Singh <[email protected]>
@workingjubilee workingjubilee added the O-UEFI UEFI label Mar 2, 2023
@Dylan-DPC
Copy link
Member

Closing this in favour of #105861

@Dylan-DPC Dylan-DPC closed this May 16, 2023
@Dylan-DPC Dylan-DPC removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label May 16, 2023
thomcc pushed a commit to tcdi/postgrestd that referenced this pull request May 31, 2023
This allows decoupling `Command::spawn` and `Command::output`. This is
useful for targets which do support launching programs in blocking mode
but do not support multitasking (Eg: UEFI).

This was originally conceived when working on rust-lang/rust#100316

Signed-off-by: Ayush Singh <[email protected]>
thomcc pushed a commit to tcdi/postgrestd that referenced this pull request May 31, 2023
Allow blocking `Command::output`

### Problem
Currently, `Command::output` is internally implemented using `Command::spawn`. This is problematic because some targets (like UEFI) do not actually support multitasking and thus block while the program is executing. This coupling does not make much sense as `Command::output` is supposed to block until the execution is complete anyway and thus does not need to rely on a non-blocking `Child` or any other intermediate.

### Solution
This PR moves the implementation of `Command::output` to `std::sys`. This means targets can choose to implement only `Command::output` without having to implement `Command::spawn`.

### Additional Information

This was originally conceived when working on rust-lang/rust#100316. Currently, the only target I know about that will benefit from this change is UEFI.

This PR can also be used to implement more efficient `Command::output` since the intermediate `Process` is not actually needed anymore, but that is outside the scope of this PR.

Since this is not a public API change, I'm not sure if an RFC is needed or not.
antoyo pushed a commit to rust-lang/rustc_codegen_gcc that referenced this pull request Jun 3, 2023
Improve generating Custom entry function

This commit is aimed at making compiler-generated entry functions (Basically just C `main` right now) more generic so other targets can do similar things for custom entry. This was initially implemented as part of rust-lang/rust#100316.

Currently, this moves the entry function name and Call convention to the target spec.

Signed-off-by: Ayush Singh <[email protected]>
Ayush1325 added a commit to Ayush1325/rust that referenced this pull request Sep 4, 2023
Implemented modules:
1. alloc
2. os_str
3. env
4. math

Tracking Issue: rust-lang#100499
API Change Proposal: rust-lang/libs-team#87

This was originally part of rust-lang#100316. Since
that PR was becoming too unwieldy and cluttered, and with suggestion
from @dvdhrm, I have extracted a minimal std implementation to this PR.

Signed-off-by: Ayush Singh <[email protected]>
Ayush1325 added a commit to Ayush1325/rust that referenced this pull request Sep 21, 2023
Implemented modules:
1. alloc
2. os_str
3. env
4. math

Tracking Issue: rust-lang#100499
API Change Proposal: rust-lang/libs-team#87

This was originally part of rust-lang#100316. Since
that PR was becoming too unwieldy and cluttered, and with suggestion
from @dvdhrm, I have extracted a minimal std implementation to this PR.

Signed-off-by: Ayush Singh <[email protected]>
Ayush1325 added a commit to Ayush1325/rust that referenced this pull request Sep 22, 2023
Implemented modules:
1. alloc
2. os_str
3. env
4. math

Tracking Issue: rust-lang#100499
API Change Proposal: rust-lang/libs-team#87

This was originally part of rust-lang#100316. Since
that PR was becoming too unwieldy and cluttered, and with suggestion
from @dvdhrm, I have extracted a minimal std implementation to this PR.

Signed-off-by: Ayush Singh <[email protected]>
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 24, 2023
…ngjubilee

Add Minimal Std implementation for UEFI

# Implemented modules:
1. alloc
2. os_str
3. env
4. math

# Related Links
Tracking Issue: rust-lang#100499
API Change Proposal: rust-lang/libs-team#87

# Additional Information
This was originally part of rust-lang#100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from `@dvdhrm,` I have extracted a minimal std implementation to this PR.

The example in `src/doc/rustc/src/platform-support/unknown-uefi.md` has been tested for `x86_64-unknown-uefi` and `i686-unknown-uefi` in OVMF. It would be great if someone more familiar with AARCH64 can help with testing for that target.

Signed-off-by: Ayush Singh <[email protected]>
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Sep 27, 2023
Add Minimal Std implementation for UEFI

# Implemented modules:
1. alloc
2. os_str
3. env
4. math

# Related Links
Tracking Issue: rust-lang/rust#100499
API Change Proposal: rust-lang/libs-team#87

# Additional Information
This was originally part of rust-lang/rust#100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from `@dvdhrm,` I have extracted a minimal std implementation to this PR.

The example in `src/doc/rustc/src/platform-support/unknown-uefi.md` has been tested for `x86_64-unknown-uefi` and `i686-unknown-uefi` in OVMF. It would be great if someone more familiar with AARCH64 can help with testing for that target.

Signed-off-by: Ayush Singh <[email protected]>
RalfJung pushed a commit to RalfJung/rust-analyzer that referenced this pull request Apr 20, 2024
  Extract WStrUnits to sys_common::wstr

This commit extracts WStrUnits from sys::windows::args to sys_common::wstr. This allows using the same structure for other targets which use wtf8 (example UEFI).

This was originally a part of rust-lang/rust#100316

Signed-off-by: Ayush Singh <[email protected]>
RalfJung pushed a commit to RalfJung/rust-analyzer that referenced this pull request Apr 27, 2024
  Extract WStrUnits to sys_common::wstr

This commit extracts WStrUnits from sys::windows::args to sys_common::wstr. This allows using the same structure for other targets which use wtf8 (example UEFI).

This was originally a part of rust-lang/rust#100316

Signed-off-by: Ayush Singh <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc O-UEFI UEFI T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.