-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 new EFIAPI ABI #65809
Add new EFIAPI ABI #65809
Conversation
Adds a new ABI for the EFIAPI calls. This ABI should reflect the latest version of the UEFI specification at the time of commit (UEFI spec 2.8, URL below). The specification says that for x86_64, we should follow the win64 ABI, while on all other supported platforms (ia32, itanium, arm, arm64 and risc-v), we should follow the C ABI. To simplify the implementation, we will simply follow the C ABI on all platforms except x86_64, even those technically unsupported by the UEFI specification. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
r? @davidtwco (rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks reasonable to me, but I'll defer to @eddyb as this isn't something an area I'm familiar with.
r? @eddyb |
Also LGTM, but I'm not sure who should approve adding new ABIs. |
src/librustc_target/spec/mod.rs
Outdated
@@ -905,6 +905,13 @@ impl Target { | |||
abi | |||
} | |||
}, | |||
Abi::EfiApi => { | |||
if self.arch != "x86_64" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is inverted, isn’t it?
We don't currently have a whitelist (ABI x only supported on platforms y, z) but we probably want that eventually (cc #57182). Doesn't have to happen in this PR, though. |
src/test/codegen/abi-efiapi.rs
Outdated
|
||
// CHECK: define win64 i64 @has_efiapi | ||
#[no_mangle] | ||
#[cfg(target_arch = "x86_64")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than using cfg
for tests here, write the test using revision feature. See https://github.com/rust-lang/rust/blob/master/src/test/codegen/optimize-attr-1.rs for an example.
src/libsyntax/feature_gate/active.rs
Outdated
@@ -531,6 +531,9 @@ declare_features! ( | |||
/// Non-object safe trait objects safe to use but cannot be created in safe rust | |||
(active, object_safe_for_dispatch, "1.40.0", Some(43561), None), | |||
|
|||
/// Allows using the `efiapi` ABI. | |||
(active, abi_efiapi, "1.40.0", Some(1), None), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please file a real tracking issue instead of directing people to #1
I have no strong objections to adding this ABI to the compiler, although I do find the |
re: name bikeshed, the name proposed in #54527 ( |
So I figured I'd keep it the same for consistency's sake. I can rename it to |
Oh dear, it's EFIAPI? Confusing, but precedent is precedent. I don't care either way, personally. |
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 |
r? @nagisa |
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 |
@bors r+ |
📌 Commit bc592e132fd20da52a6498c723efebf6e11db816 has been approved by |
@nagisa there's a tidy error :) |
Use revisions to run the EFIABI in multiple configurations, compiling for each supported UEFI platform, and checking the ABI generated in the LLVM IR is correct. Use no_core to make it easier to test.
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 |
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 |
^ How am I supposed to fix this? Is there a way to gate a test on the presence of a target in LLVM? |
I gated the test on LLVM 9.0.0 (which is when RISC-V target was added in LLVM) and now the tests pass! I think this is good to go. |
@bors r+ |
📌 Commit 1099826 has been approved by |
Add new EFIAPI ABI Fixes rust-lang#54527 Adds a new ABI, "efiapi", which reflects the calling convention as specified by [the current spec UEFI spec](https://uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G6.999903). When compiling for x86_64, we should select the `win64` ABI, while on all other architectures (Itanium, x86, ARM and ARM64 and RISC-V), we should select the `C` ABI. Currently, this is done by just turning it into the C ABI everywhere except on x86_64, where it's turned into the win64 ABI. Should we prevent this ABI from being used on unsupported architectures, and if so, how would this be done?
Add new EFIAPI ABI Fixes rust-lang#54527 Adds a new ABI, "efiapi", which reflects the calling convention as specified by [the current spec UEFI spec](https://uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G6.999903). When compiling for x86_64, we should select the `win64` ABI, while on all other architectures (Itanium, x86, ARM and ARM64 and RISC-V), we should select the `C` ABI. Currently, this is done by just turning it into the C ABI everywhere except on x86_64, where it's turned into the win64 ABI. Should we prevent this ABI from being used on unsupported architectures, and if so, how would this be done?
Add new EFIAPI ABI Fixes rust-lang#54527 Adds a new ABI, "efiapi", which reflects the calling convention as specified by [the current spec UEFI spec](https://uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G6.999903). When compiling for x86_64, we should select the `win64` ABI, while on all other architectures (Itanium, x86, ARM and ARM64 and RISC-V), we should select the `C` ABI. Currently, this is done by just turning it into the C ABI everywhere except on x86_64, where it's turned into the win64 ABI. Should we prevent this ABI from being used on unsupported architectures, and if so, how would this be done?
Rollup of 5 pull requests Successful merges: - #65294 (Lint ignored `#[inline]` on function prototypes) - #65318 (Call out the types that are non local on E0117) - #65531 (Update backtrace to 0.3.40) - #65562 (Improve the "try using a variant of the expected type" hint.) - #65809 (Add new EFIAPI ABI) Failed merges: r? @ghost
Do not require extra LLVM backends for `x.py test` to pass For long time our testing passed with a partially built LLVM ``` [llvm] targets = "X86;ARM" ``` , a [recent PR](rust-lang#65809) changed that.
Do not require extra LLVM backends for `x.py test` to pass For long time our testing passed with a partially built LLVM ``` [llvm] targets = "X86;ARM" ``` , a [recent PR](rust-lang#65809) changed that.
Do not require extra LLVM backends for `x.py test` to pass For long time our testing passed with a partially built LLVM ``` [llvm] targets = "X86;ARM" ``` , a [recent PR](rust-lang#65809) changed that.
Fixes #54527
Adds a new ABI, "efiapi", which reflects the calling convention as specified by the current spec UEFI spec. When compiling for x86_64, we should select the
win64
ABI, while on all other architectures (Itanium, x86, ARM and ARM64 and RISC-V), we should select theC
ABI.Currently, this is done by just turning it into the C ABI everywhere except on x86_64, where it's turned into the win64 ABI. Should we prevent this ABI from being used on unsupported architectures, and if so, how would this be done?