On Thursday 22 June 2017 04:44 PM, Florian Weimer wrote:
glibc performs a quick test run using valgrind as part of the build process.
Lately, this started crashing:
- elf/ld.so --library-path .:elf:nptl:dlfcn /usr/bin/valgrind elf/ld.so
--library-path .:elf:nptl:dlfcn /usr/bin/true ==924== Memcheck, a memory error detector ==924== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==924== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==924== Command: elf/ld.so --library-path .:elf:nptl:dlfcn /usr/bin/true ==924== 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) ==924== by 0x108F47: ??? (in /builddir/build/BUILD/glibc-2.25-545-g9649350/build-aarch64-redhat-linux/elf/ld.so)
The line in question is:
asm volatile ("mrs %0, midr_el1" : "=r"(id));
That seems to match the instruction bit pattern, too. There is a check around it:
This needs a valgrind patch to identify reading midr_el1 (in VEX/priv/guest_arm64_toIR.c AFAICT), which is trapped and emulated by the kernel since 4.11.
Is someone already working on this or would you like me to do this?
Siddhesh