glibc/valgrind incompatibility on POWER, potentially SCV-related

[Carl Love]

Florian, Mark:

I just put together a patch to fix the issue.  Just about to update the
bugzilla with the patch.  If you could double check that the patch
works it would be helpful.

              Carl Love


On Mon, 2021-01-04 at 22:39 +0100, Mark Wielaard wrote:
> Hi Florian,
> 
> On Mon, 2021-01-04 at 20:36 +0100, Florian Weimer wrote:
> > Does this look familiar?
> 
> It does not, but I am adding Carl and Will to the CC, who know the
> valgrind ppc64le port better.
> 
> > + /builddir/build/BUILDROOT/glibc-2.32.9000-
> > 24.fc34.ppc64le/lib64/ld-2.32.9000.so --library-path
> > /builddir/build/BUILDROOT/glibc-2.32.9000-24.fc34.ppc64le/lib64
> > /usr/bin/valgrind --error-exitcode=1
> > /builddir/build/BUILDROOT/glibc-2.32.9000-24.fc34.ppc64le/lib64/ld-
> > 2.32.9000.so --library-path /builddir/build/BUILDROOT/glibc-
> > 2.32.9000-24.fc34.ppc64le/lib64 /usr/bin/true
> > ==3891888== Memcheck, a memory error detector
> > ==3891888== Copyright (C) 2002-2017, and GNU GPL'd, by Julian
> > Seward et al.
> > ==3891888== Using Valgrind-3.16.1 and LibVEX; rerun with -h for
> > copyright info
> > ==3891888== Command: /builddir/build/BUILDROOT/glibc-2.32.9000-
> > 24.fc34.ppc64le/lib64/ld-2.32.9000.so --library-path
> > /builddir/build/BUILDROOT/glibc-2.32.9000-24.fc34.ppc64le/lib64
> > /usr/bin/true
> > ==3891888== 
> > dis_syslink(ppc)(theInstr)
> > disInstr(ppc): unhandled instruction: 0x44000001
> >                  primary 17(0x11), secondary 1(0x1)
> > ==3891888== valgrind: Unrecognised instruction at address
> > 0x4999f80.
> > ==3891888==    at 0x4999F80: _Exit (in
> > /builddir/build/BUILDROOT/glibc-2.32.9000-
> > 24.fc34.ppc64le/lib64/libc-2.32.9000.so)
> > ==3891888==    by 0x48ED76B: __run_exit_handlers (in
> > /builddir/build/BUILDROOT/glibc-2.32.9000-
> > 24.fc34.ppc64le/lib64/libc-2.32.9000.so)
> > ==3891888==    by 0x48C9FBB: generic_start_main.constprop.0.isra.0
> > (in /builddir/build/BUILDROOT/glibc-2.32.9000-
> > 24.fc34.ppc64le/lib64/libc-2.32.9000.so)
> > ==3891888==    by 0x48CA19F: (below main) (in
> > /builddir/build/BUILDROOT/glibc-2.32.9000-
> > 24.fc34.ppc64le/lib64/libc-2.32.9000.so)
> > ==3891888== Your program just tried to execute an instruction that
> > Valgrind
> > ==3891888== did not recognise.  There are two possible reasons for
> > this.
> > ==3891888== 1. Your program has a bug and erroneously jumped to a
> > non-code
> > ==3891888==    location.  If you are running Memcheck and you just
> > saw a
> > ==3891888==    warning about a bad jump, it's probably your
> > program's fault.
> > ==3891888== 2. The instruction is legitimate but Valgrind doesn't
> > handle it,
> > ==3891888==    i.e. it's Valgrind's fault.  If you think this is
> > the case or
> > ==3891888==    you are not sure, please let us know and we'll try
> > to fix it.
> > ==3891888== Either way, Valgrind will now raise a SIGILL signal
> > which will
> > ==3891888== probably kill your program.
> > ==3891888== 
> > ==3891888== Process terminating with default action of signal 4
> > (SIGILL): dumping core
> > ==3891888==  Illegal opcode at address 0x4999F80
> > ==3891888==    at 0x4999F80: _Exit (in
> > /builddir/build/BUILDROOT/glibc-2.32.9000-
> > 24.fc34.ppc64le/lib64/libc-2.32.9000.so)
> > ==3891888==    by 0x48ED76B: __run_exit_handlers (in
> > /builddir/build/BUILDROOT/glibc-2.32.9000-
> > 24.fc34.ppc64le/lib64/libc-2.32.9000.so)
> > ==3891888==    by 0x48C9FBB: generic_start_main.constprop.0.isra.0
> > (in /builddir/build/BUILDROOT/glibc-2.32.9000-
> > 24.fc34.ppc64le/lib64/libc-2.32.9000.so)
> > ==3891888==    by 0x48CA19F: (below main) (in
> > /builddir/build/BUILDROOT/glibc-2.32.9000-
> > 24.fc34.ppc64le/lib64/libc-2.32.9000.so)
> > ==3891888== 
> > ==3891888== HEAP SUMMARY:
> > ==3891888==     in use at exit: 0 bytes in 0 blocks
> > ==3891888==   total heap usage: 0 allocs, 0 frees, 0 bytes
> > allocated
> > ==3891888== 
> > ==3891888== All heap blocks were freed -- no leaks are possible
> > ==3891888== 
> > ==3891888== For lists of detected and suppressed errors, rerun
> > with: -s
> > 
> > I will try to get the exact object file.
> > 
> > My guess it's the SCV instruction, introduced by:
> > 
> > commit 68ab82f56690ada86ac1e0c46bad06ba189a10ef
> > Author: Matheus Castanho <msc@linux.ibm.com>
> > Date:   Thu Dec 3 14:15:27 2020 -0300
> > 
> >     powerpc: Runtime selection between sc and scv for syscalls
> > 
> > The immediate fix would be to mask PPC_FEATURE2_SCV in hwcap2.
> 
> Yes, that looks plausible.
> 
> > Shouldn't valgrind conservatively mask everything?
> 
> It probably should, and some arches do, but ppc64le checks for
> specific
> values (see setup_client_stack in coregrind/m_initimg/initimg-
> linux.c).
> 
> Thanks for filing 
> https://bugs.kde.org/show_bug.cgi?id=431157
>  
> 
> Cheers,
> 
> Mark