-
Notifications
You must be signed in to change notification settings - Fork 14.5k
Description
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