This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: valgrind support for glibc master
- From: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at gotplt dot org>, The GNU C Library support for Fedora <glibc at lists dot fedoraproject dot org>, Mark Wielaard <mark at klomp dot org>
- Date: Thu, 22 Jun 2017 12:17:52 +0100
- Subject: Re: valgrind support for glibc master
- Authentication-results: sourceware.org; auth=none
- References: <4cc2a089-aa95-61e3-19ff-437efda1b420@redhat.com>
On Thu, Jun 22, 2017 at 12:14 PM, Florian Weimer <fweimer@redhat.com> 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));
This instruction actually traps to the kernel and comes back with the
right value for MIDR with some emulation in the kernel. I suspect you
are looking at a valgrind issue here.
regards
Ramana
>
> 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