I think it's a "dcbzl" cache line zeroing instruction. The valgrind folks already have a bug filed for it: http://bugs.kde.org/show_bug.cgi?id=135264
I don't know how hard it would be to add to VEX/valgrind. Probably easy for someone like Julian who knows that code well, harder for someone like me who has only skimmed it. The code already supports other similar instructions like "dcbz" (VEX/priv/guest_ppc_toIR.c: 5667), so it might not be too tricky. I think that the "l" suffix just means that it applies to full 128-byte cache blocks instead of 32 bytes. -Dave On Apr 9, 2010, at 1:53 AM, Mogens Lindholdt Lauridsen wrote: > > Hi, > > I got this message from valgrind: > > dis_cache_manage(ppc)(opc1|b21to25|b0) > disInstr(ppc): unhandled instruction: 0x7C2907EC > primary 31(0x1F), secondary 2028(0x7EC) > ==714== valgrind: Unrecognised instruction at address 0x10d410e0. > ==714== Your program just tried to execute an instruction that > Valgrind > ==714== did not recognise. There are two possible reasons for this. > ==714== 1. Your program has a bug and erroneously jumped to a non-code > ==714== location. If you are running Memcheck and you just saw a > ==714== warning about a bad jump, it's probably your program's > fault. > ==714== 2. The instruction is legitimate but Valgrind doesn't handle > it, > ==714== i.e. it's Valgrind's fault. If you think this is the > case or > ==714== you are not sure, please let us know and we'll try to fix > it. > ==714== Either way, Valgrind will now raise a SIGILL signal which will > ==714== probably kill your program. > ==714== > ==714== Process terminating with default action of signal 4 > (SIGILL): dumping core > ==714== Illegal opcode at address 0x10D410E0 > ==714== at 0x10D410E0: dsputil_init_ppc (dsputil_ppc.c:222) > ==714== by 0x10CF5053: dsputil_init (dsputil.c:4693) > ==714== by 0x10CD306F: aac_decode_init (aac.c:472) > ==714== by 0x10CCEAAB: avcodec_open (utils.c:484) > ==714== by 0x10CB311F: av_find_stream_info (utils.c:1887) > > This is FFMpeg code running on a PPC. > > It seems like problem has been seen before: > http://www.mail-archive.com/gn...@gnu.org/msg01640.html > > I am using valgrind/VEX from Trunk, and I believe that it is these > revisions: > Valgrind revision 11029 > VEX revision 1959 > > Does anybody know if this instruction is valid? And how to add this > to VEX, if it is missing? > > / > Mogens > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev_______________________________________________ > Valgrind-users mailing list > Valgrind-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/valgrind-users ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
