Re: [Valgrind-developers] CPU: e500v2

[John R. <jr...@bi...>]

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