valgrind support for glibc master

[Szabolcs Nagy]

On 22/06/17 12:14, 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));
> 

note that this is an instruction that is emulated by the
kernel now (the register read is not available to userspace)

so it's understandable that valgrind does not understand it yet.

> That seems to match the instruction bit pattern, too.  There is a check
> around it:
> 
>   if (hwcap & HWCAP_CPUID)
>     {
>       register uint64_t id = 0;
>       asm volatile ("mrs %0, midr_el1" : "=r"(id));
>       cpu_features->midr_el1 = id;
>     }
>   else
>     cpu_features->midr_el1 = 0;
> 
> I think this code is fine.  Unfortunately, I don't know if I'll be able
> to get a disassembly or debug this any further.  There are a couple of
> potential causes (GLRO (dl_hwcap) is not initialized correctly in glibc,
> HWCAP_CPUID is not masked by the kernel or valgrind despite the lack of
> support, GCC schedule the volatile asm statement before the condition).
> 
> Is anyone else seeing this?
> 
> I will disable the valgrind sanity test during the Fedora build for the
> time being.
> 
> Thanks,
> Florian
>