valgrind support for glibc master
by Florian Weimer
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:
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
6 years, 9 months
[PATCH] Update the i18n, UTF-8 and translit_* files to Unicode 10.0.0
by Mike FABIAN
Unicode 10.0.0 has been released recently (2017-06-20).
Here is a patch to update the i18n, tr_TR, UTF-8, and the translit_*
files to Unicode 10.0.0.
I have sent this patch also to the libc-alpha mailing list (against
current master of glibc).
This patch is for rawhide.
Do we also want this for Fedora 26?
--
Mike FABIAN <mfabian(a)redhat.com>
睡眠不足はいい仕事の敵だ。
6 years, 9 months
CVE-2017-1000366 fixes
by Florian Weimer
Hi,
I managed to push the CVE-2017-1000366 fix to rawhide through a resync.
It's building now.
I have not yet touched the older Fedora branches (the upstream backports
should be done, though), and I need a bit of sleep. I'll pick up the
leftovers tomorrow morning and create Bodhi updates as needed.
Florian
6 years, 9 months
[WIP] Fix F26 build.
by Carlos O'Donell
Arjun,
Attached is my WIP patch to fix the f26 build.
Would you mind running with this patch?
* Build locally and check it fixes things (mockbuild)
* Scratch build for all arches, and double check no testsuite regression.
* File a fedora bug for this and use the bug number for the fix.
* Post final patches here (public glibc(a)lists.fedoraproject.org) for review.
* Start running through the bodhi process to update f26 with this fix.
Thanks!
Mike,
This should unblock you from using f26.
--
Cheers,
Carlos.
6 years, 10 months