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&#174; 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&#174; 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&#174; 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&#174; 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

Reply via email to