GNU libgcrypt ATT asm style. Clang (llmv-as) doesn't pass autotool configure check unified asm code support


I found a strange libgcrypt behavior on ARM with clang built.

There is a big gap in performance of libgcrypt, built by clang, in comparison with gcc on my ARM target machine.
The simple profile test shows 100-500% advantage of gcc gcrypt.
I found an awkward workaround to beat this issue, but need your help to find the best way to fix it.

The root cause is next:
GNU binutils historically support AT&T asm style with %register name.
Due to clang strict assembler syntax rules the unified assembler ARM check doesn’t pass.
Assembler check fails while ./configure for flags:

As a workaround I remove ‘%’ from registers names in,
arm mips lib *.S files,
cipher/*arm.S,*armv7-neon.S files.

Could you please help with a more correct - polite way to compile libgcrypt with assembler code?

Tested on:


build machine:
intel based cpu x86_64

compiler : clang 11.1.0
linker lld : lld 11.1.0
assembler : llvm-as 11.1.0
cflags : “-m32 -march=armv7-a -mthumb -mfpu=vfpv3-d16 --target=arm-linux-gnueabihf”

arm-linux-gnueabihf sysroot based on glibc 2.31

libgcrypt configuring:
–with-libgpg-error-prefix=< path>

target machine:
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 2304.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae aes pmull sha1 sha2 crc32

1 Like

Last time I looked at non-UAS was more than 10 years ago, but back then we decided not to support non-UAS for good. So there’s little hope for Clang to ever support changes to make that work today.

All Arm toolchains today, and for many many years, support UAS, so even back then, the “fix” was always to update the source code instead. Projects where we clean that up extensively were the Linux kernel, Android and I think even Chromium had some issues back then.

So I’m sure gcrypt would be happy to accept a patch improving their assembler syntax and in turn, allowing Clang to compile their code.

1 Like