We link some core/tools with libgcc for helper functions. For gcc10 libgcc added a dependency on glibc getauxval. But we don't link against glibc. Causing: gcc -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fasynchronous-unwind-tables -fstack-clash-protection -Wl,-z,relro -Wl,--as-needed -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o memcheck-arm64-linux -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-signedness -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wlogical-op -Wenum-conversion -Wimplicit-fallthrough=2 -Wold-style-declaration -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin -O2 -static -nodefaultlibs -nostartfiles -u _start memcheck_arm64_linux-mc_leakcheck.o memcheck_arm64_linux-mc_malloc_wrappers.o memcheck_arm64_linux-mc_main.o memcheck_arm64_linux-mc_main_asm.o memcheck_arm64_linux-mc_translate.o memcheck_arm64_linux-mc_machine.o memcheck_arm64_linux-mc_errors.o ../coregrind/libcoregrind-arm64-linux.a ../VEX/libvex-arm64-linux.a -lgcc /usr/bin/ld: /usr/lib/gcc/aarch64-redhat-linux/10/libgcc.a(lse-init.o): in function `init_have_lse_atomics': (.text.startup+0xc): undefined reference to `__getauxval' (.text.startup+0xc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__getauxval' collect2: error: ld returned 1 exit status We would need to provide a (fake) __getauxval() in coregrind/m_compiler.c. See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91833 There is a build time fix in case the libc used to build libgcc doesn't provide getauxval, but that doesn't help us at runtime. https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/aarch64/lse-init.c;hb=HEAD static void __attribute__((constructor)) init_have_lse_atomics (void) { unsigned long hwcap = __getauxval (AT_HWCAP); __aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0; }
Note that -lgcc comes last in the link line, because it provides symbols some of the earlier objects need. We'll need to arrange for our "fake" __getauxval to be provided after -lgcc. Also note that the only thing tested is whether AT_HWCAP contains HWCAP_ATOMICS. So all we need to do is figure out whether or not to set bit 8 ("atomics") or not.
Created attachment 128393 [details] Patch to provide a new library with symbols for libgcc Provide a new library libgcc-sup-<platform>.a that contains symbols needed by libgcc. This needs to be linked after -lgcc to provide any symbols missing which would normally be provided by glibc. At the moment this only provides __getauxval on arm64 linux. Note that this patch currently also adds HWCAP_ATOMICS to ARM64_SUPPORTED_HWCAP since commit f1cf734554320e92f0dfc80125dfc2a7e5356ff2 "Bug 369509 - ARMv8.1-a LSE instructions are not supported" seems to have added them now. But although that seems to work, it also causes drd/tests/std_mutex to hang (even with --tool=none). It looks like only one thread is able to get the lock and release it. But none of the other threads ever get it and they all end up in a futex wait syscall. So, unless we can figure out what is going on there I think it might be best to (at least on the 3.16.0 branch) to not enable HWCAP_ATOMICS.
Created attachment 128471 [details] Fix patch for std_mutex spin bug
(In reply to ahashmi from comment #3) > Created attachment 128471 [details] > Fix patch for std_mutex spin bug Nice! That fixes the hang for me. Note that I already pushed the libgcc supplemental patch to git master. What is still missing is: diff --git a/coregrind/m_initimg/initimg-linux.c b/coregrind/m_initimg/initimg-l inux.c index 0b44f825d..bab8aeca0 100644 --- a/coregrind/m_initimg/initimg-linux.c +++ b/coregrind/m_initimg/initimg-linux.c @@ -705,7 +705,8 @@ Addr setup_client_stack( void* init_sp, { /* Limit the AT_HWCAP to just those features we explicitly support in VEX. */ -#define ARM64_SUPPORTED_HWCAP (VKI_HWCAP_AES \ +#define ARM64_SUPPORTED_HWCAP (VKI_HWCAP_ATOMICS \ + | VKI_HWCAP_AES \ | VKI_HWCAP_PMULL \ | VKI_HWCAP_SHA1 \ | VKI_HWCAP_SHA2 \ Plus your patch.
commit abbc0761fa0349d49b10dc8c0f10af6bc0578c40 Author: Mark Wielaard <mark@klomp.org> Date: Tue May 12 16:58:36 2020 +0200 gcc10 arm64 build needs __getauxval for linking with libgcc Provide a new library libgcc-sup-<platform>.a that contains symbols needed by libgcc. This needs to be linked after -lgcc to provide any symbols missing which would normally be provided by glibc. At the moment this only provides __getauxval on arm64 linux. https://bugs.kde.org/show_bug.cgi?id=421321 The other arm64 issues are tracked in https://bugs.kde.org/show_bug.cgi?id=421570