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

Hello,

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:
HAVE_COMPATIBLE_GCC_ARM_PLATFORM_AS
HAVE_GCC_INLINE_ASM_NEON

As a workaround I remove ‘%’ from registers names in
configure.ac,
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:
libgcrypt-1.8.6
libgcrypt-1.9.3

Equipment:

build machine:
intel based cpu x86_64
Ubnuntu-20.04

Software
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:
CC=“arm-linux-gnueabihf-clang”
./configure
–with-libgpg-error-prefix=<libgpg.so path>
–prefix=
–host=arm-linux-gnueabihf
–enable-static
–disable-doc

target machine:
hardware:
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