Proposal: extern "uefi" ABI

[HadrienG2]

The UEFI firmware interface has some calling conventions which are documented in chapter 2.3 of the current spec.

For the most part, these are pretty close to the Windows ABI conventions ("cdecl" on IA-32, "win64" on AMD64...), which should come as no surprise given the strong influence that Microsoft has on the UEFI forum. However, the UEFI spec also defines calling conventions for hardware architectures like RISC-V where Windows has not been ported.

UEFI applications (such as OS loaders) must be extra careful to use the right ABI when calling into UEFI, since unless you are Windows, extern "C" will not necessarily map into what the firmware expects.

In rust-osdev/uefi-rs#41 , @GabrielMajeri proposed to make the life of UEFI application developers easier by adding language-level support for the UEFI FFI in the form of an extern "uefi" ABI. How open would you be to this idea?

[eddyb]

cc @rust-lang/compiler @alexcrichton

[steveklabnik]

Is this discussion better had here or on internals?

[HadrienG2]

Whichever way you like best 😉

[parched]

How do the C compilers handle this?

[petrochenkov]

I wonder if it's possible to support custom ABIs through some plugin-based interface.
You write some Rust code describing how the ABI works, then link it proc macro style, then use the new ABI.

(Disclaimer: I have no idea how the current ABI definitions work, and what interface the ABI plugin should have, especially for calling conventions.)

[eddyb]

@petrochenkov It's very close to being pure data, so I would prefer to have it mostly be described in JSON, or something like that, if possible. (I've considered it before, albeit not in a purely declarative manner, it's mostly a matter of "resource categorization and allocation")

Everything other than calling conventions is already described through the "datalayout" string, and I'd prefer to avoid adding plugin systems to rustc, as they impose significant technical burden.

---

OTOH, us gathering call ABIs ("calling conventions") for various targets comes at almost 0 cost and since it's all isolated in a rustc_target library with no dependencies on the compiler, we can even merge efforts with Cranelift, to make it easy to build upon those ABI definitions (cc @sunfishcode).

The "mainstream" approach of rewriting all the rules for all the targets, by hand, in every compiler, is a waste of effort, and unshares knowledge, and rustc can do a public service here.

[Centril]

I say let's do it :)

[GabrielMajeri]

How do the C compilers handle this?

The C compilers make a distinction between "different calling conventions" and "same calling convention name, different ABIs".

GCC and Clang support custom function attributes which allow one to write __cdecl __attribute__((ms_abi)) vs __cdecl __attribute__((sysv_abi)).

Also, this attribute has no effect on non-x86_64, so everything fits perfectly. In our use case, extern "win64" is allowed on 32-bit (weird) and it generates code different from extern "C".

As for usage of this feature: it is used in gnuefi (for UEFI calling convention) and wine (for building ELF files with Windows calling conventions).

I would prefer to have it mostly be described in JSON, or something like that

Interesting, but my question is, how can we make this composable and allow this to work with libraries?
If we have a library providing UEFI bindings, it should be its responsability to define extern "uefi", instead of relying on downstream binaries to include JSON in their build script.

[estebank]

I would prefer to have it mostly be described in JSON, or something like that

Interesting, but my question is, how can we make this composable and allow this to work with libraries?
If we have a library providing UEFI bindings, it should be its responsability to define extern "uefi", instead of relying on downstream binaries to include JSON in their build script.

I believe the point is to make it configurable on our end, so that adding new extern targets can be done purely with metadata, instead of changing rustc code. That doesn't mean that developers would be required to come up with their own files for any of the supported calling conventions ("C"/"uefi"), but it would enable them to come up with their own if needed (regardless on wether a rustc would be needed ^_^).

[Rua]

This seems like a good idea to me. Like extern "C", this would simply be an alias for different things on different platforms, and new mappings could be added if UEFI ever gets extended to new platforms in the future.