This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: valgrind support for glibc master


On Thu, 2017-06-22 at 16:58 +0530, Siddhesh Poyarekar wrote:
> 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?

As far as I know, nobody is working on this yet. So if you can then
please do. Even if you don't know how to fix the valgrind side just
filing a bug report with the expected behavior of the missing emulation
would be appreciated.
https://bugs.kde.org/enter_bug.cgi?product=valgrind

Maybe valgrind should just filter out the HWCAP_CPUID? Trying to figure
out why this started failing. I assume 4.10 didn't set that, but that it
is now set by the 4.11 kernel?

Thanks,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]