|
From: John R. <jr...@bi...> - 2015-04-05 03:36:05
|
> I still get the error: disInstr(ppc): unhandled instruction: 0x10E40301 > I thought Valgrind 3.10.1 has support for CPU: e500v2? NO? 0x10E40301 ==> "evldd r7,0(r4)". Developers are much more likely to recognize 'evldd' than an instruction word in hex. It is customary to give some documented basis for "I thought ...". Just a little bit of searching the bug list: https://bugs.kde.org Product: valgrind Content: e500 yields this report from 2010-10-28 (4.5 years ago), last updated 2013-04-02 (two years ago): https://bugs.kde.org/show_bug.cgi?id=255494 which links to this attachment from a run of valgrind-3.6.0: https://bugs.kde.org/attachment.cgi?id=52939 which contains: ----- disInstr(ppc): unhandled instruction: 0x10E40301 primary 4(0x4), secondary 769(0x301) ==19630== valgrind: Unrecognised instruction at address 0x4019510. [[snip]] ==19630== Process terminating with default action of signal 4 (SIGILL): dumping core ==19630== Illegal opcode at address 0x4019510 ==19630== at 0x4019510: memcpy (in /lib/ld-2.8.so) ==19630== by 0x40021BF: _dl_start_final (in /lib/ld-2.8.so) ==19630== by 0x40162C7: _start (in /lib/ld-2.8.so) ----- So that code for memcpy has an optimization to fetch at least 64 bits at a time in some circumstances, instead of only 32 bits. Evidently valgrind-3.10.1 still does not implement this instruction. Your best bet is to comment on bug 255494, requesting implementation. You could help by supplying a list of missing opcodes which, if implemented, would be sufficient for valgrind to handle all of memcpy. Until then, avoid code that contains this optimization. Install a more-generic version of /lib/ld-2.8.so that does not use the specialized instructions. |