Bug 342610

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.

I am so sorry, I will give more information on this issue as soon as possible.thank you for your answer

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?

Sorry,I apologize for my last sentence, should I need it to provide additional information?

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 ***