Tracking issue for the "efiapi" calling convention #65815
Comments
jonas-schievink
added
B-unstable
joshtriplett
added
S-tracking-impl-incomplete
workingjubilee
added
the
A-ABI
Supported architectures in UEFI are described here: https://uefi.org/specs/UEFI/2.10/02_Overview.html#calling-conventions rust-lang#65815
…, r=nagisa Limit efiapi calling convention to supported arches Supported architectures in UEFI are described here: https://uefi.org/specs/UEFI/2.10/02_Overview.html#calling-conventions rust-lang#65815
Supported architectures in UEFI are described here: https://uefi.org/specs/UEFI/2.10/02_Overview.html#calling-conventions Changes to tests modeled on 8240e7a. rust-lang#65815
On arm, llvm treats the C calling convention as `aapcs` on soft-float targets and `aapcs-vfp` on hard-float targets [1]. UEFI specifies in the arm calling convention that floating point extensions aren't used [2], so always translate `efiapi` to `aapcs` on arm. [1]: rust-lang/compiler-builtins#116 (comment) [2]: https://uefi.org/specs/UEFI/2.10/02_Overview.html#detailed-calling-convention rust-lang#65815
…, r=nagisa Limit efiapi calling convention to supported arches Supported architectures in UEFI are described here: https://uefi.org/specs/UEFI/2.10/02_Overview.html#calling-conventions rust-lang#65815
…r=nagisa Use aapcs for efiapi calling convention on arm On arm, [llvm treats the C calling convention as `aapcs` on soft-float targets and `aapcs-vfp` on hard-float targets](rust-lang/compiler-builtins#116 (comment)). UEFI specifies in the arm calling convention that [floating point extensions aren't used](https://uefi.org/specs/UEFI/2.10/02_Overview.html#detailed-calling-convention), so always translate `efiapi` to `aapcs` on arm. rust-lang#65815
…r=nagisa Use aapcs for efiapi calling convention on arm On arm, [llvm treats the C calling convention as `aapcs` on soft-float targets and `aapcs-vfp` on hard-float targets](rust-lang/compiler-builtins#116 (comment)). UEFI specifies in the arm calling convention that [floating point extensions aren't used](https://uefi.org/specs/UEFI/2.10/02_Overview.html#detailed-calling-convention), so always translate `efiapi` to `aapcs` on arm. rust-lang#65815
…r=JohnTitor unstable-book: Add page for the `abi_efiapi` feature Tracking issue for `abi_efiapi`: rust-lang#65815
…r=JohnTitor unstable-book: Add page for the `abi_efiapi` feature Tracking issue for `abi_efiapi`: rust-lang#65815
|
The two known issues identified in the issue description have been resolved. Stabilization ReportSummaryThis feature adds the extern "efiapi" fn func() { todo!() }When compiling for a UEFI target such as The UEFI ABI can only be used on architectures where UEFI is supported: #104020 Some examples of usage in the Rust UEFI ecosystem: For background on why the ABI is named Documentation
Tests
|
|
I think this should be stabilized together with |
IMO that doesn't need to be a blocker for |
joshtriplett
added
S-tracking-ready-to-stabilize
|
Shall we stabilieze the @rfcbot merge |
|
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
|
Pondering: how much value do we get from lang FCPs for calling conventions? Could we define everything related to syntax and semantics independent of the set of values that actually are supported as CC values? Does the language spec ever really need to care if someone wants My instinct is that the existence of particular calling conventions would be far better as a T-compiler decision (like for targets), and lang would only come into it for things with semantic impact, like if someone wishes to add a feature for, say, |
|
@scottmcm I do think we should be reviewing new ABI proposals, yes. Among other things, some ABIs may be proposed to solve problems that may be better solved a different way or with more comprehensive interactions (e.g. defining naked functions or interrupt handlers). Some ABIs may be supported across many targets (like this one). Some ABIs may have interactions with the set of types or function attributes permitted. This ABI also raised other language issues, such as the availability of specific ABIs on targets that don't support them. So in general, while I think most ABIs will be uncontroversial, I don't think they should pass by without review. |
|
@rfcbot reviewed |
rfcbot
added
the
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
removed
the
proposed-final-comment-period
rfcbot
added
finished-final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Tracking issue: rust-lang#65815
Each `bindgen` release may upgrade the list of Rust targets. For instance,
currently, in their master branch [1], the latest ones are:
Nightly => {
vectorcall_abi: #124485,
ptr_metadata: #81513,
layout_for_ptr: #69835,
},
Stable_1_77(77) => { offset_of: #106655 },
Stable_1_73(73) => { thiscall_abi: #42202 },
Stable_1_71(71) => { c_unwind_abi: #106075 },
Stable_1_68(68) => { abi_efiapi: #105795 },
By default, the highest stable release in their list is used, and users
are expected to set one if they need to support older Rust versions
(e.g. see [2]).
Thus, over time, new Rust features are used by default, and at some
point, it is likely that `bindgen` will emit Rust code that requires a
Rust version higher than our minimum (or perhaps enabling an unstable
feature). Currently, there is no problem because the maximum they have,
as seen above, is Rust 1.77.0, and our current minimum is Rust 1.78.0.
Therefore, set a Rust target explicitly now to prevent going forward in
time too much and thus getting potential build failures at some point.
Since we also support a minimum `bindgen` version, and since `bindgen`
does not support passing unknown Rust target versions, we need to use
the list of our minimum `bindgen` version, rather than the latest. So,
since `bindgen` 0.65.1 had this list [3], we need to use Rust 1.68.0:
/// Rust stable 1.64
/// * `core_ffi_c` ([Tracking issue](rust-lang/rust#94501))
=> Stable_1_64 => 1.64;
/// Rust stable 1.68
/// * `abi_efiapi` calling convention ([Tracking issue](rust-lang/rust#65815))
=> Stable_1_68 => 1.68;
/// Nightly rust
/// * `thiscall` calling convention ([Tracking issue](rust-lang/rust#42202))
/// * `vectorcall` calling convention (no tracking issue)
/// * `c_unwind` calling convention ([Tracking issue](rust-lang/rust#74990))
=> Nightly => nightly;
...
/// Latest stable release of Rust
pub const LATEST_STABLE_RUST: RustTarget = RustTarget::Stable_1_68;
Thus add the `--rust-target 1.68` parameter. Add a comment as well
explaining this.
An alternative would be to use the currently running (i.e. actual) `rustc`
and `bindgen` versions to pick a "better" Rust target version. However,
that would introduce more moving parts depending on the user setup and
is also more complex to implement.
Cc: Christian Poveda <git@pvdrz.com>
Cc: Emilio Cobos Álvarez <emilio@crisal.io>
Link: https://github.com/rust-lang/rust-bindgen/blob/21c60f473f4e824d4aa9b2b508056320d474b110/bindgen/features.rs#L97-L105 [1]
Link: rust-lang/rust-bindgen#2960 [2]
Link: https://github.com/rust-lang/rust-bindgen/blob/7d243056d335fdc4537f7bca73c06d01aae24ddc/bindgen/features.rs#L131-L150 [3]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Tracking issue for the
efiapicalling convention, added in PR #65809. The feature gate name isabi_efiapi.The
efiapicalling convention can be used for defining a function with an ABI compatible with the UEFI Interfaces as defined in the UEFI Specification. On the currently supported platform, this means selecting between thewin64ABI or theCABI depending on the target architecture.Usage
Known Issues
aapcson ARM, andaapcs64en ARM64, instead of delegating toC.The text was updated successfully, but these errors were encountered: