Illegal instruction errors in chromium on raspberrypi4 (64-bit) when built with `-mcpu=cortex-a72`

[kraj]

When chromium 118 (embedded in QTWebengine in my case ) is compiled with clang and -mcpu=cortex-a72 option is passed to compiler, the chromium's build system ends up enabling crypto extensions when compiling boringSSL and boringSSL generates code which expects HW AES instructions from CPU but the CPU inside RPI4 seems to not implement AES+SHA2 h/w blocks [1]

chromium/boringSSL checks for compiler's internal define __ARM_FEATURE_CRYPTO [2] being defined to enable H/W AES for arm64 in boringSSL

Then I compared gcc and clang and it seems they differ and gcc is doing the right thing.

aarch64-yoe-linux-clang -mcpu=cortex-a72 -dD -E -x c /dev/null | grep __ARM_FEATURE_AES
#define __ARM_FEATURE_AES 1

aarch64-yoe-linux-gcc -mcpu=cortex-a72 -dD -E -x c /dev/null | grep __ARM_FEATURE_AES
#undef __ARM_FEATURE_AES

same is true for __ARM_FEATURE_CRYPTO

I think clang/llvm assumes that if CPU is cortex-a72 then AES and SHA2 extensions are also available, but they are optional and needs additional license to be implemented.

Perhaps defaults for -mcpu=cortex-a72 should be changes in llvm/clang to not include them and if user asks with -mcpu=cortex-a72+crypto or -mcpu=cortex-a72+crypto+aes then it should enable it.

[1] https://forums.raspberrypi.com/viewtopic.php?f=63&t=207888 [2] https://boringssl.googlesource.com/boringssl/+/refs/heads/master/crypto/internal.h#1557

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Khem Raj (kraj)

When chromium 118 (embedded in QTWebengine in my case ) is compiled with clang and -mcpu=cortex-a72 option is passed to compiler, the chromium's build system ends up enabling crypto extensions when compiling boringSSL and boringSSL generates code which expects HW AES instructions from CPU but the CPU inside RPI4 seems to not implement AES+SHA2 h/w blocks [1] chromium/boringSSL checks for compiler's internal define __ARM_FEATURE_CRYPTO [2] being defined to enable H/W AES for arm64 in boringSSL Then I compared gcc and clang and it seems they differ and gcc is doing the right thing. ``` aarch64-yoe-linux-clang -mcpu=cortex-a72 -dD -E -x c /dev/null | grep __ARM_FEATURE_AES #define __ARM_FEATURE_AES 1 ``` ``` aarch64-yoe-linux-gcc -mcpu=cortex-a72 -dD -E -x c /dev/null | grep __ARM_FEATURE_AES #undef __ARM_FEATURE_AES ``` same is true for __ARM_FEATURE_CRYPTO I think clang/llvm assumes that if CPU is cortex-a72 then AES and SHA2 extensions are also available, but they are optional and needs additional license to be implemented. Perhaps defaults for `-mcpu=cortex-a72` should be changes in llvm/clang to not include them and if user asks with `-mcpu=cortex-a72+crypto` or `-mcpu=cortex-a72+crypto+aes` then it should enable it. [1] https://forums.raspberrypi.com/viewtopic.php?f=63&t=207888 [2] https://boringssl.googlesource.com/boringssl/+/refs/heads/master/crypto/internal.h#1557

[v01dXYZ]

Hi,

disabling aes with -mcpu=cortex-a72+noaes solves the problem (or if you just want to add it to CFLAGS you can with -Xclang -target-feature -Xclang -aes). Nevertheless, you're right the default are wrong:

https://github.com/llvm/llvm-project/blob/53ff002c6f7ec64a75ab0990b1314cc6b4bb67cf/llvm/include/llvm/TargetParser/AArch64TargetParser.h#L573-L575