Bug 342610 - disInstr(ppc): declined to decode an AltiVec insn.
Summary: disInstr(ppc): declined to decode an AltiVec insn.
Status: RESOLVED DUPLICATE of bug 275786
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (other bugs)
Version First Reported In: 3.10.0
Platform: PCLinuxOS Other
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-08 08:09 UTC by zhaoyafei
Modified: 2015-04-26 18:20 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description zhaoyafei 2015-01-08 08:09:01 UTC
when I run this:
/usr/bin/valgrind --show-below-main=yes --sigill-diagnostics=no /usr/bin/brdmanager
result:
==1093== Memcheck, a memory error detector
	==1093== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
	==1093== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
	==1093== Command: /usr/bin/brdmanager
	==1093== disInstr(ppc): declined to decode an AltiVec insn.
	==1093== 
	==1093== Process terminating with default action of signal 4 (SIGILL)
	==1093==  Illegal opcode at address 0x100CA6DC
	==1093==    at 0x100CA6DC: generic_start_main (in /usr/bin/brdmanager)
	==1093==    by 0x100CA9EF: __libc_start_main (in /usr/bin/brdmanager)
	==1093== 
	==1093== HEAP SUMMARY:
	==1093==     in use at exit: 0 bytes in 0 blocks
	==1093==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
	==1093== 
	==1093== All heap blocks were freed -- no leaks are possible
	==1093== 
	==1093== For counts of detected and suppressed errors, rerun with: -v
	==1093== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
	Illegal instruction


cpu:Freescale QorIQ p1010 and base on linux-2.6.37

Can someone help me?
thanks very much!

Reproducible: Always
Comment 1 Florian Krohm 2015-01-08 15:17:18 UTC
Nobody will be able to help you without knowing the instruction that could not be decoded. We're good, but not that good.
Rerun without --sigill-diagnostics=no. Then post the output here. There should be something like

vex ppc64->IR: unhandled instruction bytes: 0xF 0x1 0xD0 0x48 0x89 0xC3 0x48 0x89
.....

in the output. That is the important part.
Comment 2 zhaoyafei 2015-01-09 02:35:36 UTC
I am so sorry, I will give more information on this issue as soon as possible.thank you for your answer
Comment 3 zhaoyafei 2015-01-09 03:07:04 UTC
uname –a
Linux (none) 2.6.37-gc0a6b7e #1 Wed Jan 7 21:49:52 CST 2015 ppc GNU/Linux

cat /proc/cpuinfo
processor		: 0
cpu			: e500v2
clock			: 800.000000MHz
revision		: 5.2 (pvr 8021 2152)
bogomips		: 100.00
timebase		: 50000000
platform		: P1010 RDB
model		: fsl,P1010
Memory		: 512 MB

/usr/bin/valgrind --show-below-main=yes /usr/bin/brdmanager:
==1849== Memcheck, a memory error detector
==1849== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1849== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==1849== Command: /usr/bin/brdmanager
==1849==
disInstr(ppc): declined to decode an AltiVec insn.
disInstr(ppc): unhandled instruction: 0x13AB0B21
                 primary 4(0x4), secondary 801(0x321)
==1849== valgrind: Unrecognised instruction at address 0x100b3660.
==1849==    at 0x100B3660: generic_start_main (in /usr/bin/brdmanager)
==1849==    by 0x100B3973: __libc_start_main (in /usr/bin/brdmanager)
==1849== Your program just tried to execute an instruction that Valgrind
==1849== did not recognise.  There are two possible reasons for this.
==1849== 1. Your program has a bug and erroneously jumped to a non-code
==1849==    location.  If you are running Memcheck and you just saw a
==1849==    warning about a bad jump, it's probably your program's fault.
==1849== 2. The instruction is legitimate but Valgrind doesn't handle it,
==1849==    i.e. it's Valgrind's fault.  If you think this is the case or
==1849==    you are not sure, please let us know and we'll try to fix it.
==1849== Either way, Valgrind will now raise a SIGILL signal which will
==1849== probably kill your program.
==1849==
==1849== Process terminating with default action of signal 4 (SIGILL)
==1849==  Illegal opcode at address 0x100B3660
==1849==    at 0x100B3660: generic_start_main (in /usr/bin/brdmanager)
==1849==    by 0x100B3973: __libc_start_main (in /usr/bin/brdmanager)
==1849==
==1849== HEAP SUMMARY:
==1849==     in use at exit: 0 bytes in 0 blocks
==1849==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1849==
==1849== All heap blocks were freed -- no leaks are possible
==1849==
==1849== For counts of detected and suppressed errors, rerun with: -v
==1849== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction

And run it: 
/usr/bin/valgrind --show-below-main=yes ps
==1914== Memcheck, a memory error detector
==1914== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1914== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==1914== Command: ps
==1914==
disInstr(ppc): unhandled instruction: 0x10E40301
                 primary 4(0x4), secondary 769(0x301)
==1914== valgrind: Unrecognised instruction at address 0x40199f0.
==1914==    at 0x40199F0: memcpy (in /lib/ld-2.11.1.so)
==1914==    by 0x400558F: _dl_start_final (in /lib/ld-2.11.1.so)
==1914==    by 0x4016383: _start (in /lib/ld-2.11.1.so)
==1914== Your program just tried to execute an instruction that Valgrind
==1914== did not recognise.  There are two possible reasons for this.
==1914== 1. Your program has a bug and erroneously jumped to a non-code
==1914==    location.  If you are running Memcheck and you just saw a
==1914==    warning about a bad jump, it's probably your program's fault.
==1914== 2. The instruction is legitimate but Valgrind doesn't handle it,
==1914==    i.e. it's Valgrind's fault.  If you think this is the case or
==1914==    you are not sure, please let us know and we'll try to fix it.
==1914== Either way, Valgrind will now raise a SIGILL signal which will
==1914== probably kill your program.
==1914==
==1914== Process terminating with default action of signal 4 (SIGILL)
==1914==  Illegal opcode at address 0x40199F0
==1914==    at 0x40199F0: memcpy (in /lib/ld-2.11.1.so)
==1914==    by 0x400558F: _dl_start_final (in /lib/ld-2.11.1.so)
==1914==    by 0x4016383: _start (in /lib/ld-2.11.1.so)
==1914==
==1914== HEAP SUMMARY:
==1914==     in use at exit: 0 bytes in 0 blocks
==1914==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1914==
==1914== All heap blocks were freed -- no leaks are possible
==1914==
==1914== For counts of detected and suppressed errors, rerun with: -v
==1914== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 2)
Illegal instruction

Will you need additional information?
Comment 4 zhaoyafei 2015-01-09 03:14:33 UTC
Sorry,I apologize for my last sentence, should I need it to provide additional information?
Comment 5 Florian Krohm 2015-04-26 18:20:44 UTC
Sorry for the late response... So there were two instructions that were not supported:
0x13AB0B21 and 0x10E40301
The first one is vmhraddshs v29,v11,v1,v12 and that appears to be supported in the valgrind development sources. Whether it is supported in 3.10.1 I do not know.
The second instruction is still unsupported. It has been reported already in bug #275786.
So I'm closing this bug report as a duplicate.

*** This bug has been marked as a duplicate of bug 275786 ***