Bug 421321

Summary:	gcc10 arm64 build needs __getauxval for linking with libgcc
Product:	[Developer tools] valgrind	Reporter:	Mark Wielaard <mark>
Component:	general	Assignee:	Mark Wielaard <mark>
Status:	RESOLVED FIXED
Severity:	normal	CC:	assad.hashmi
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Patch to provide a new library with symbols for libgcc Fix patch for std_mutex spin bug

Description Mark Wielaard 2020-05-11 09:19:43 UTC

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;
}

Comment 1 Mark Wielaard 2020-05-11 10:45:45 UTC

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.

Comment 2 Mark Wielaard 2020-05-12 15:19:50 UTC

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.

Comment 3 ahashmi 2020-05-15 10:27:43 UTC

Created attachment 128471 [details]
Fix patch for std_mutex spin bug

Comment 4 Mark Wielaard 2020-05-15 14:18:23 UTC

(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.

Comment 5 Mark Wielaard 2020-05-15 14:54:09 UTC

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