That's using a patched valgrind? Did you forget to "make && make install" in the top level valgrind directory? Perhaps check the timestamps on your installation files versus your source file... (ls - lt /VG_PREFIX/lib/valgrind/libvex-* /VG_SRC/VEX/priv/guest_ppc_toIR.c)
I build my test program with a very similar command: "gcc -g -save- temps dcbzl.c -o dcbzl". I'm also using gcc 4.1.2. If I run "/usr/bin/valgrind ./dcbzl" I get a failure message almost exactly like yours. If I run "/path/to/my/valgrind ./dcbzl" I get a clean run. -Dave On Apr 13, 2010, at 3:42 PM, Mogens Lindholdt Lauridsen wrote: > > I just tried your testprogram. I compiled it like this: (gcc 4.1.2) > /opt/wrsysroot/x86-linux2/powerpc-wrs-linux-gnu-ppc_603e-glibc_small- > gcc -g dcbzl.c -o dcbzl > > And something went wrong....: > > # /home/mln/TargetTools/valgrind/install_svn_debug_modified/bin/ > valgrind /home/mln/dcbzl > ==823== Memcheck, a memory error detector > ==823== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et > al. > ==823== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for > copyright info > ==823== Command: /home/mln/dcbzl > ==823== > dis_cache_manage(ppc)(opc1|b21to25|b0) > disInstr(ppc): unhandled instruction: 0x7C2907EC > primary 31(0x1F), secondary 2028(0x7EC) > ==823== valgrind: Unrecognised instruction at address 0x10000938. > ==823== Your program just tried to execute an instruction that > Valgrind > ==823== did not recognise. There are two possible reasons for this. > ==823== 1. Your program has a bug and erroneously jumped to a non-code > ==823== location. If you are running Memcheck and you just saw a > ==823== warning about a bad jump, it's probably your program's > fault. > ==823== 2. The instruction is legitimate but Valgrind doesn't handle > it, > ==823== i.e. it's Valgrind's fault. If you think this is the > case or > ==823== you are not sure, please let us know and we'll try to fix > it. > ==823== Either way, Valgrind will now raise a SIGILL signal which will > ==823== probably kill your program. > ==823== > ==823== Process terminating with default action of signal 4 (SIGILL): > dumping core > ==823== Illegal opcode at address 0x10000938 > ==823== at 0x10000938: dcbzl (dcbzl.c:16) > ==823== by 0x100005FF: main (dcbzl.c:35) > ==823== > ==823== HEAP SUMMARY: > ==823== in use at exit: 384 bytes in 1 blocks > ==823== total heap usage: 1 allocs, 0 frees, 384 bytes allocated > ==823== > ==823== LEAK SUMMARY: > ==823== definitely lost: 0 bytes in 0 blocks > ==823== indirectly lost: 0 bytes in 0 blocks > ==823== possibly lost: 0 bytes in 0 blocks > ==823== still reachable: 384 bytes in 1 blocks > ==823== suppressed: 0 bytes in 0 blocks > ==823== Rerun with --leak-check=full to see details of leaked memory > ==823== > ==823== For counts of detected and suppressed errors, rerun with: -v > ==823== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) > Illegal instruction > # > > Hm.... ??? > > > > Dave Goodell <good...@mcs.anl.gov> > 13-04-2010 22:28 > > To > Mogens Lindholdt Lauridsen <m...@bang-olufsen.dk> > cc > valgrind-users@lists.sourceforge.net > Subject > Re: [Valgrind-users] PPC: unhandled instruction: 0x7C2907EC > > > > > > I already attached a simple testcase to the ticket [1], although there > are always more ways that it could be tested. My test case just makes > sure that exactly the cache block requested is zeroed, regardless of > which address in the block is used. > > -Dave > > [1] http://bugsfiles.kde.org/attachment.cgi?id=42750 > > On Apr 13, 2010, at 2:58 PM, Mogens Lindholdt Lauridsen wrote: > > > > > Wow! That was fast. > > > > I will try to apply your patch, and see how it works. > > > > Unfortunately the execution of this instruction is very rare. I have > > been running valgrind on our application for something like 500 > > hours and only seen this one time. I guess that the trigger for this > > piece of code is dependent on the input data from the internet radio > > and also timing. > > > > I will see if I can make a testcase to prove your patch. > > > > Thanks! > > > > Best regards, > > Mogens > > > > > > > > Dave Goodell <good...@mcs.anl.gov> > > 13-04-2010 17:39 > > > > To > > Dave Goodell <good...@mcs.anl.gov> > > cc > > valgrind-users@lists.sourceforge.net, Mogens Lindholdt Lauridsen > > <m...@bang-olufsen.dk > > > > > Subject > > Re: [Valgrind-users] PPC: unhandled instruction: 0x7C2907EC > > > > > > > > > > > > FWIW, I've attached a small patch that seems to fix this problem to > > the ticket discussed earlier: https://bugs.kde.org/show_bug.cgi?id=135264 > > > > I'm not a PPC/POWER expert by any means, so the patch may not be > > sufficiently general. But it seemed to work fine on the PPC970 > system > > that I was using. > > > > -Dave > > > > On Apr 9, 2010, at 12:29 PM, Dave Goodell wrote: > > > > > 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 > > > > > > > ------------------------------------------------------------------------------ > > 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
