Tracking issue for the "efiapi" calling convention

[roblabla]

Tracking issue for the efiapi calling convention, added in PR #65809. The feature gate name is abi_efiapi.

The efiapi calling 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 the win64 ABI or the C ABI depending on the target architecture.

Usage

extern "efiapi" fn func() {…}

Known Issues

• The ABI is currently accessible on platforms architectures not supported by UEFI (x86, x86_64, itanium, arm, arm64 and risc-v). There is currently no way to whitelist ABI for certain architectures, see AAPCS ABI is accepted for x86 target #57182 for a similar issue.
• EFIAPI should delegate to aapcs on ARM, and aapcs64 en ARM64, instead of delegating to C.

[nicholasbishop]

The two known issues identified in the issue description have been resolved.

Stabilization Report

Summary

This feature adds the efiapi ABI for functions. This ABI is defined in the UEFI Specification. Example usage:

extern "efiapi" fn func() { todo!() }

When compiling for a UEFI target such as x86_64-unknown-uefi this ABI is already the default, but UEFI functions can also be called from code compiled for other targets. For example, a kernel might be compiled as an ELF executable, but to call a UEFI service it needs to use the proper UEFI ABI.

The UEFI ABI can only be used on architectures where UEFI is supported: #104020

Some examples of usage in the Rust UEFI ecosystem:

• r-efi
• uefi-rs

For background on why the ABI is named efiapi, see #65809 (comment)

Documentation

• Unstable Book: https://doc.rust-lang.org/nightly/unstable-book/language-features/abi-efiapi.html
• Reference: PR #1309

Tests

• Check that the correct annotation for the efiapi ABI is passed to llvm: https://github.com/rust-lang/rust/blob/master/src/test/codegen/abi-efiapi.rs

[lukas-code]

I think this should be stabilized together with extended_varargs_abi_support, because some UEFI functions (InstallMultipleProtocolInterfaces / UninstallMultipleProtocolInterfaces) depend on that.

[nicholasbishop]

I think this should be stabilized together with extended_varargs_abi_support, because some UEFI functions (InstallMultipleProtocolInterfaces / UninstallMultipleProtocolInterfaces) depend on that.

IMO that doesn't need to be a blocker for efiapi. There are very few functions in the UEFI spec that rely on varargs, so it doesn't matter much that it's not yet supported.

[joshtriplett]

Shall we stabilieze the extern "efiapi" calling convention?

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

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.

[scottmcm]

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 extern "fluffy"? Would a compiler ever be considered non-compliant for not supporting the "efiabi" calling convention?

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, as casting between fns with different ABIs. Certainly I don't feel like I personally have any useful feedback to offer here.

[joshtriplett]

@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.

[nikomatsakis]

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

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.