ARMv8.0-A baseline binary or ARMv8.2-A tuned build for mixed aarch64 CI?

Question

Shared aarch64 build target
Goal: ship one repeatable aarch64 binary or library that executes without SIGILL on heterogeneous physical hosts and under QEMU user-mode emulation, while still using optional CPU extensions where available.
Compiling with -march=armv8-a targets the mandatory ARMv8.0-A baseline and maximizes portability across Cortex-A72, Neoverse N1, Apple silicon, and emulated guests, but forgoes optional-extension speedups. Building with -march=armv8.2-a or -mcpu=neoverse-n1 can use SHA3, CRC32, FP16, or enhanced atomics, yet may fail on cores or QEMU CPU models that do not expose those features.
glibc IFUNC and getauxval(AT_HWCAP) permit runtime dispatch, but the build must still decide which instruction set to compile into each variant and which baseline to link. QEMU may present a synthetic feature set that differs from physical silicon, and KVM does not pass through all optional AArch64 features by default, so CI results under emulation may not match real hardware.
Should the shared artifact target ARMv8.0-A with optional-extension IFUNC dispatch, or compile separate ARMv8.2-A artifacts and select them at deployment? Is getauxval(AT_HWCAP) sufficient to gate optional-extension code paths reliably across kernel and QEMU versions?

Tasadduq Burney · Answer

ARMv8.0-A Baseline is the required choice for maximum CI portability.
The shared artifact must target the ARMv8.0-A baseline using -march=armv8-a. This guarantees execution without SIGILL across the diverse set of physical hosts (Cortex-A72, Neoverse N1, etc.) and QEMU emulation environments present in the mixed aarch64 CI.

Explanation and Confirmed Facts

Portability over Features: Targeting ARMv8.0-A maximizes the lowest common denominator, ensuring the binary runs everywhere, whereas ARMv8.2-A introduces dependencies on optional extensions (SHA3, FP16) that QEMU or older cores may not expose.
Runtime Dispatch Uncertainty: While glibc IFUNC or getauxval(AT_HWCAP) allow for runtime dispatch of optional code paths, the reliability of AT_HWCAP across varying kernel and QEMU versions is not guaranteed and cannot substitute for a safe baseline build.
Deployment Complexity: Building and managing separate ARMv8.2-A variants adds unnecessary deployment complexity compared to a single, robust baseline artifact.

Necessary Steps

Compile the artifact using -march=armv8-a.
Implement optional extension logic using runtime checks (e.g., feature detection via system calls or library introspection) rather than relying solely on compile-time flags for extensions.
Verify execution on the lowest common denominator physical host.

Diagnostic Inquiry
To confirm the recommendation, please specify the exact kernel version running within the QEMU user-mode emulation environment used by the CI system.

ARMv8.0-A baseline binary or ARMv8.2-A tuned build for mixed aarch64 CI?

Shared aarch64 build target

1 answer

ARMv8.0-A Baseline is the required choice for maximum CI portability.

Explanation and Confirmed Facts

Necessary Steps

Diagnostic Inquiry

Your perspective belongs here.

0 question comments