* glibc/valgrind incompatibility on POWER, potentially SCV-related
@ 2021-01-04 19:36 Florian Weimer
2021-01-04 19:57 ` Florian Weimer
2021-01-04 21:39 ` Mark Wielaard
0 siblings, 2 replies; 4+ messages in thread
From: Florian Weimer @ 2021-01-04 19:36 UTC (permalink / raw)
To: Mark Wielaard
Cc: Matheus Castanho, Tulio Magno Quites Machado Filho, libc-alpha
Does this look familiar?
+ /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.
Shouldn't valgrind conservatively mask everything?
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: glibc/valgrind incompatibility on POWER, potentially SCV-related
2021-01-04 19:36 glibc/valgrind incompatibility on POWER, potentially SCV-related Florian Weimer
@ 2021-01-04 19:57 ` Florian Weimer
2021-01-04 21:39 ` Mark Wielaard
1 sibling, 0 replies; 4+ messages in thread
From: Florian Weimer @ 2021-01-04 19:57 UTC (permalink / raw)
To: Florian Weimer via Libc-alpha
Cc: Mark Wielaard, Tulio Magno Quites Machado Filho
* Florian Weimer via Libc-alpha:
> 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.
It's SCV, confirmed by vgdb:
Dump of assembler code for function __GI__exit:
0x0000000004995fa0 <+0>: addis r2,r12,18
0x0000000004995fa4 <+4>: addi r2,r2,4448
0x0000000004995fa8 <+8>: mflr r0
0x0000000004995fac <+12>: nop
0x0000000004995fb0 <+16>: std r29,-24(r1)
0x0000000004995fb4 <+20>: std r31,-8(r1)
0x0000000004995fb8 <+24>: ld r9,-29584(r2)
0x0000000004995fbc <+28>: mr r31,r3
0x0000000004995fc0 <+32>: std r30,-16(r1)
0x0000000004995fc4 <+36>: add r29,r9,r13
0x0000000004995fc8 <+40>: li r30,-4096
0x0000000004995fcc <+44>: mr r3,r31
0x0000000004995fd0 <+48>: std r0,16(r1)
0x0000000004995fd4 <+52>: li r0,234
0x0000000004995fd8 <+56>: ld r9,-28776(r13)
0x0000000004995fdc <+60>: andis. r9,r9,16
0x0000000004995fe0 <+64>: beq 0x4996034 <__GI__exit+148>
0x0000000004995fe4 <+68>: nop
0x0000000004995fe8 <+72>: nop
0x0000000004995fec <+76>: ori r2,r2,0
=> 0x0000000004995ff0 <+80>: scv 0
I filed: <https://bugs.kde.org/show_bug.cgi?id=431157>
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: glibc/valgrind incompatibility on POWER, potentially SCV-related
2021-01-04 19:36 glibc/valgrind incompatibility on POWER, potentially SCV-related Florian Weimer
2021-01-04 19:57 ` Florian Weimer
@ 2021-01-04 21:39 ` Mark Wielaard
2021-01-04 21:50 ` Carl Love
1 sibling, 1 reply; 4+ messages in thread
From: Mark Wielaard @ 2021-01-04 21:39 UTC (permalink / raw)
To: Florian Weimer
Cc: Matheus Castanho, Tulio Magno Quites Machado Filho, libc-alpha,
cel, will_schmidt
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: glibc/valgrind incompatibility on POWER, potentially SCV-related
2021-01-04 21:39 ` Mark Wielaard
@ 2021-01-04 21:50 ` Carl Love
0 siblings, 0 replies; 4+ messages in thread
From: Carl Love @ 2021-01-04 21:50 UTC (permalink / raw)
To: Mark Wielaard, Florian Weimer
Cc: Matheus Castanho, Tulio Magno Quites Machado Filho, libc-alpha,
will_schmidt
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-01-04 21:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-04 19:36 glibc/valgrind incompatibility on POWER, potentially SCV-related Florian Weimer
2021-01-04 19:57 ` Florian Weimer
2021-01-04 21:39 ` Mark Wielaard
2021-01-04 21:50 ` Carl Love
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).