uefi-test-runner aarch64: LLVM ERROR: Unsupported calling convention

[rijenkii]

When trying to compile uefi-test-runner from master for aarch64, the following happens:

➜  uefi-test-runner git:(master) git checkout master
Already on 'master'
Your branch is up to date with 'origin/master'.
➜  uefi-test-runner git:(master) cargo clean
➜  uefi-test-runner git:(master) ./build.py run --target aarch64
   Compiling compiler_builtins v0.1.45
   Compiling core v0.0.0 (/home/rijenkii/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling proc-macro2 v1.0.27
   Compiling unicode-xid v0.2.2
   Compiling syn v1.0.73
   Compiling bitflags v1.2.1
   Compiling log v0.4.14
   Compiling quote v1.0.9
   Compiling uefi-macros v0.3.3 (/tmp/uefi-rs/uefi-macros)
   Compiling rustc-std-workspace-core v1.99.0 (/home/rijenkii/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling alloc v0.0.0 (/home/rijenkii/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc)
   Compiling cfg-if v1.0.0
   Compiling bit_field v0.10.1
   Compiling qemu-exit v2.0.0
   Compiling rlibc v1.0.0
   Compiling ucs2 v0.3.2
   Compiling uefi v0.11.0 (/tmp/uefi-rs)
   Compiling uefi-services v0.8.0 (/tmp/uefi-rs/uefi-services)
LLVM ERROR: Unsupported calling convention.
error: could not compile `uefi`

To learn more, run the command again with --verbose.
Subprocess cargo exited with error code 101

No such problem occurs on v0.11.0 commit (7773aca).

[GabrielMajeri]

Hmm, the only "non-standard" calling convention we use (besides efiapi) is the sysv64 one.

@josephlr does the extern "sysv64" calling convention used for ShimLock also applies on AArch64 systems? If not, is the shim protocol supported on that architecture?

[rijenkii]

I found that commit 9db727c is indeed the one that seems to break stuff.

➜  uefi-test-runner git:(a13ddfe) git checkout a13ddfe
HEAD is now at a13ddfe Add `num_blocks` method to `GptPartitionEntry` (#238)
➜  uefi-test-runner git:(a13ddfe) ./build.py build --target aarch64
   Compiling uefi v0.11.0 (/tmp/uefi-rs)
   Compiling uefi-services v0.8.0 (/tmp/uefi-rs/uefi-services)
   Compiling uefi-test-runner v0.2.0 (/tmp/uefi-rs/uefi-test-runner)
    Finished dev [unoptimized + debuginfo] target(s) in 1.12s

➜  uefi-test-runner git:(a13ddfe) git checkout 9db727c
Previous HEAD position was a13ddfe Add `num_blocks` method to `GptPartitionEntry` (#238)
HEAD is now at 9db727c shim: ShimLock protocol uses "sysv64" function ABI (#227)
➜  uefi-test-runner git:(9db727c) ./build.py build --target aarch64
   Compiling uefi v0.11.0 (/tmp/uefi-rs)
   Compiling uefi-services v0.8.0 (/tmp/uefi-rs/uefi-services)
LLVM ERROR: Unsupported calling convention.
error: could not compile `uefi`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed
Subprocess cargo exited with error code 101

[josephlr]

@josephlr does the extern "sysv64" calling convention used for ShimLock also applies on AArch64 systems? If not, is the shim protocol supported on that architecture?

Yes the Shim is supported on AArch64 (or at the very least they have Makefiles for ARM targets). It seems like both the shim and Grub (the two current users of the protocol) define it using the "C" calling convention:

• Shim: https://github.com/rhboot/shim/blob/05875f3aed1c90fe071c66de05744ca2bcbc2b9e/shim.h#L194-L223
• Grub: https://github.com/rhboot/grub2/blob/a53e530f8ad3770c3b03c208c08ae4162f68e3b1/include/grub/efi/api.h#L1714
  Systemd-boot uses a #define macro to choose the right ABI: https://github.com/systemd/systemd/blob/b5ce2feebc8bcc02e03661de9d49b3ea0cd064a4/src/boot/efi/shim.c#L17-L21

[josephlr]

@GabrielMajeri it might be fine to just declare these as extern "C", but do you know what the C calling convention is for x86_64-unknown-uefi?

[GabrielMajeri]

@josephlr as far as I know the x86_64-unknown-uefi target uses the MSVC 64-bit calling convention by default (since the UEFI platform on x86 is similar to Windows). Will probably need some cfg-based calling conventions there.