SIGILL in detect_arm_hwf_by_toolchain under FreeBSD arm64 on a Raspberry Pi 4B

[Jussi Kivilinna]

On 10.7.2024 19.39, Jussi Kivilinna wrote:
> Hello,
> 
> On 9.7.2024 20.49, Naram Qashat via Gcrypt-devel wrote:
>> I don't know if this started to happen after I updated to FreeBSD 14.1 on my RPi4B, but libgcrypt crashes with a SIGILL in detect_arm_hwf_by_toolchain on line 527 when trying to run the assembly code there. As a result, I cannot use gnupg either. I asked about this in one of the FreeBSD IRC channels and this was the conversation about it:
> 
> Looking at documentation for __ARM_FEATURE_CRYPTO (https://github.com/ARM-software/acle/releases/download/r2024Q2/acle-2024Q2.pdf):
> 
> "__ARM_FEATURE_CRYPTO is defined to 1 if the Armv8-A Crypto instructions are supported and intrinsics targeting them are available. These instructions include AES{E, D}, SHA1{C, P, M} and others. This also implies __ARM_FEATURE_AES and __ARM_FEATURE_SHA2."
> 
> And as __ARM_FEATURE_AES is implied:
> 
> "__ARM_FEATURE_AES is defined to 1 if there is hardware support for the Advanced SIMD AES Crypto instructions from Armv8-A ..."
> 
> Based on this, libgcrypt has been compiled using CPU target that supports crypto-extensions, but actually HW does not support. Did you use "-mcpu=cortex-a72" for compiler flags to select CPU type? If compiler is enabling crypto-extensions for "-mcpu=cortex-a72" and crypto-extensions are actually optional for Cortex-A72 then bug must be in compiler... "-mcpu=cortex-a72" setting should not be selecting optional crypto-extensions by default. Which compiler are you using? GCC or clang or something else? Which version?

I found this LLVM bug, Cortex-A72 defaults are wrong there:
  https://github.com/llvm/llvm-project/issues/85699

Looking at GCC documentation, GCC "-mcpu=cortex-a72" does not enable crypto extensions by default. Instead one needs "-mcpu=cortex-a72+crypto" to enable CE with A72.
  https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

-Jussi