valgrind currently does not know anything about the CPUID flag added to the HWCAP auxv entry in kernel 4.11. It passes this flag through to applications, but it will then choke when the application uses it, like this:
ARM64 front end: branch_etc
disInstr(arm64): unhandled instruction 0xD5380000
disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0000
==924== valgrind: Unrecognised instruction at address 0x11f548.
==924== at 0x11F548: init_cpu_features (cpu-features.c:32)
==924== by 0x11F548: dl_platform_init (dl-machine.h:241)
==924== by 0x11F548: _dl_sysdep_start (dl-sysdep.c:231)
==924== by 0x10981B: _dl_start_final (rtld.c:412)
==924== by 0x109AAB: _dl_start (rtld.c:520)
This is from a newer glibc (not the one in Red Hat Enterprise Linux). The crashing instruction is the mrs in the glibc startup code:
if (hwcap & HWCAP_CPUID)
register uint64_t id = 0;
asm volatile ("mrs %0, midr_el1" : "=r"(id));
cpu_features->midr_el1 = id;
cpu_features->midr_el1 = 0;
Perhaps valgrind should mask all the HWCAP bits it knows nothing about.
Workaround: Run with “LD_HWCAP_MASK=1”.
The upstream bug is https://bugs.kde.org/show_bug.cgi?id=381556
arm64: Handle feature registers access on 4.11 Linux kernel or later
Fedora valgrind-3.13.0-3.fc27 contains a workaround, see bug https://bugzilla.redhat.com/show_bug.cgi?id=1464211
Verified with build valgrind-3.13.0-10.el7.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.