-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 i686-unknown-uefi target #64334
Add i686-unknown-uefi target #64334
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @matthewjasper (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
This adds a new rustc target-configuration called 'i686-unknown_uefi'. This is similar to existing x86_64-unknown_uefi target. The i686-unknown-uefi target can be used to build Intel Architecture 32bit UEFI application. The ABI defined in UEFI environment (aka IA32) is similar to cdecl. We choose i686-unknown-uefi-gnu instead of i686-unknown-uefi to avoid the intrinsics generated by LLVM. The detail of root-cause and solution analysis is added as comment in the code. For x86_64-unknown-uefi, we cannot use -gnu, because the ABI between MSVC and GNU is totally different, and UEFI chooses ABI similar to MSVC. For i686-unknown-uefi, the UEFI chooses cdecl ABI, which is same as MSVC and GNU. According to LLVM code, the only differences between MSVC and GNU are fmodf(f32), longjmp() and TLS, which have no impact to UEFI. As such, using i686-unknown-uefi-gnu is the simplest way to pass the build. Adding the undefined symbols, such as _aulldiv() to rust compiler-builtins is out of scope. But it may be considered later. The scope of this patch is limited to support target-configuration. No standard library support is added in this patch. Such work can be done in future enhancement. Cc: Josh Triplett <[email protected]> Reviewed-by: Josh Triplett <[email protected]>
Sorry, didn't see this when it was first posted. This looks good to me, and will allow further development on this target. Once merged, we can experiment further outside of rustc (using @bors r+ |
📌 Commit 21e062d has been approved by |
Add i686-unknown-uefi target This adds a new rustc target-configuration called 'i686-unknown_uefi'. This is similar to existing x86_64-unknown_uefi target. The i686-unknown-uefi target can be used to build Intel Architecture 32bit UEFI application. The ABI defined in UEFI environment (aka IA32) is similar to cdecl. We choose i686-unknown-uefi-gnu instead of i686-unknown-uefi to avoid the intrinsics generated by LLVM. The detail of root-cause and solution analysis is added as comment in the code. For x86_64-unknown-uefi, we cannot use -gnu, because the ABI between MSVC and GNU is totally different, and UEFI chooses ABI similar to MSVC. For i686-unknown-uefi, the UEFI chooses cdecl ABI, which is same as MSVC and GNU. According to LLVM code, the only differences between MSVC and GNU are fmodf(f32), longjmp() and TLS, which have no impact to UEFI. As such, using i686-unknown-uefi-gnu is the simplest way to pass the build. Adding the undefined symbols, such as _aulldiv() to rust compiler-builtins is out of scope. But it may be considered later. The scope of this patch is limited to support target-configuration. No standard library support is added in this patch. Such work can be done in future enhancement. Cc: Josh Triplett <[email protected]> Reviewed-by: Josh Triplett <[email protected]>
☀️ Test successful - checks-azure |
Pkgsrc changes: * Remove patch which no longer applies (but what about RPATH?) * Adapt a few patches to changed files upstream. Upstream changes: Version 1.39.0 (2019-11-07) =========================== Language -------- - [You can now create `async` functions and blocks with `async fn`, `async move {}`, and `async {}` respectively, and you can now call `.await` on async expressions.][63209] - [You can now use certain attributes on function, closure, and function pointer parameters.][64010] These attributes include `cfg`, `cfg_attr`, `allow`, `warn`, `deny`, `forbid` as well as inert helper attributes used by procedural macro attributes applied to items. e.g. ```rust fn len( #[cfg(windows)] slice: &[u16], #[cfg(not(windows))] slice: &[u8], ) -> usize { slice.len() } ``` - [You can now take shared references to bind-by-move patterns in the `if` guards of `match` arms.][63118] e.g. ```rust fn main() { let array: Box<[u8; 4]> = Box::new([1, 2, 3, 4]); match array { nums // ---- `nums` is bound by move. if nums.iter().sum::<u8>() == 10 // ^------ `.iter()` implicitly takes a reference to `nums`. => { drop(nums); // ----------- Legal as `nums` was bound by move and so we have ownership. } _ => unreachable!(), } } ``` Compiler -------- - [Added tier 3\* support for the `i686-unknown-uefi` target.][64334] - [Added tier 3 support for the `sparc64-unknown-openbsd` target.][63595] - [rustc will now trim code snippets in diagnostics to fit in your terminal.] [63402] **Note** Cargo currently doesn't use this feature. Refer to [cargo#7315][cargo/7315] to track this feature's progress. - [You can now pass `--show-output` argument to test binaries to print the output of successful tests.][62600] \* Refer to Rust's [platform support page][forge-platform-support] for more information on Rust's tiered platform support. Libraries --------- - [`Vec::new` and `String::new` are now `const` functions.][64028] - [`LinkedList::new` is now a `const` function.][63684] - [`str::len`, `[T]::len` and `str::as_bytes` are now `const` functions.][63770] - [The `abs`, `wrapping_abs`, and `overflowing_abs` numeric functions are now `const`.][63786] Stabilized APIs --------------- - [`Pin::into_inner`] - [`Instant::checked_duration_since`] - [`Instant::saturating_duration_since`] Cargo ----- - [You can now publish git dependencies if supplied with a `version`.] [cargo/7237] - [The `--all` flag has been renamed to `--workspace`.][cargo/7241] Using `--all` is now deprecated. Misc ---- - [You can now pass `-Clinker` to rustdoc to control the linker used for compiling doctests.][63834] Compatibility Notes ------------------- - [Code that was previously accepted by the old borrow checker, but rejected by the NLL borrow checker is now a hard error in Rust 2018.][63565] This was previously a warning, and will also become a hard error in the Rust 2015 edition in the 1.40.0 release. - [`rustdoc` now requires `rustc` to be installed and in the same directory to run tests.][63827] This should improve performance when running a large amount of doctests. - [The `try!` macro will now issue a deprecation warning.][62672] It is recommended to use the `?` operator instead. - [`asinh(-0.0)` now correctly returns `-0.0`.][63698] Previously this returned `0.0`. [62600]: rust-lang/rust#62600 [62672]: rust-lang/rust#62672 [63118]: rust-lang/rust#63118 [63209]: rust-lang/rust#63209 [63402]: rust-lang/rust#63402 [63565]: rust-lang/rust#63565 [63595]: rust-lang/rust#63595 [63684]: rust-lang/rust#63684 [63698]: rust-lang/rust#63698 [63770]: rust-lang/rust#63770 [63786]: rust-lang/rust#63786 [63827]: rust-lang/rust#63827 [63834]: rust-lang/rust#63834 [63927]: rust-lang/rust#63927 [63933]: rust-lang/rust#63933 [63934]: rust-lang/rust#63934 [63938]: rust-lang/rust#63938 [63940]: rust-lang/rust#63940 [63941]: rust-lang/rust#63941 [63945]: rust-lang/rust#63945 [64010]: rust-lang/rust#64010 [64028]: rust-lang/rust#64028 [64334]: rust-lang/rust#64334 [cargo/7237]: rust-lang/cargo#7237 [cargo/7241]: rust-lang/cargo#7241 [cargo/7315]: rust-lang/cargo#7315 [`Pin::into_inner`]: https://doc.rust-lang.org/std/pin/struct.Pin.html#method.into_inner [`Instant::checked_duration_since`]: https://doc.rust-lang.org/std/time/struct.Instant.html#method.checked_duration_since [`Instant::saturating_duration_since`]: https://doc.rust-lang.org/std/time/struct.Instant.html#method.saturating_duration_since
- aarch64-unknown-none: rust-lang/rust#68334 - aarch64-unknown-none-softfloat: rust-lang/rust#64589 - armv7-unknown-linux-gnueabi: rust-lang/rust#63107 - armv7-unknown-linux-musleabi: rust-lang/rust#63107 - aarch64-apple-tvos: rust-lang/rust#68191 - armv7a-none-eabihf: rust-lang/rust#68253 - i686-unknown-uefi: rust-lang/rust#64334 - thumbv7neon-unknown-linux-musleabihf: rust-lang/rust#66103 - x86_64-apple-ios-macabi: rust-lang/rust#63467 - x86_64-apple-tvos: rust-lang/rust#68191 - x86_64-linux-kernel: rust-lang/rust#64051 - x86_64-unknown-hermit-kernel: rust-lang/rust#66713 - x86_64-unknown-illumos: rust-lang/rust#71145 Moved to tier 2: - aarch64-unknown-none: rust-lang/rust#68334
This adds a new rustc target-configuration called 'i686-unknown_uefi'.
This is similar to existing x86_64-unknown_uefi target.
The i686-unknown-uefi target can be used to build Intel Architecture
32bit UEFI application. The ABI defined in UEFI environment (aka IA32)
is similar to cdecl.
We choose i686-unknown-uefi-gnu instead of i686-unknown-uefi to avoid
the intrinsics generated by LLVM. The detail of root-cause and solution
analysis is added as comment in the code.
For x86_64-unknown-uefi, we cannot use -gnu, because the ABI between
MSVC and GNU is totally different, and UEFI chooses ABI similar to MSVC.
For i686-unknown-uefi, the UEFI chooses cdecl ABI, which is same as
MSVC and GNU. According to LLVM code, the only differences between MSVC
and GNU are fmodf(f32), longjmp() and TLS, which have no impact to UEFI.
As such, using i686-unknown-uefi-gnu is the simplest way to pass the build.
Adding the undefined symbols, such as _aulldiv() to rust compiler-builtins
is out of scope. But it may be considered later.
The scope of this patch is limited to support target-configuration.
No standard library support is added in this patch. Such work can be
done in future enhancement.
Cc: Josh Triplett [email protected]
Reviewed-by: Josh Triplett [email protected]