|
From: Mogens L. L. <ML...@ba...> - 2010-04-09 07:09:25
|
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...@gn.../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 |
|
From: Dave G. <go...@mc...> - 2010-04-09 17:29:35
|
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...@gn.../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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dave G. <go...@mc...> - 2010-04-13 15:37:05
|
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...@gn.../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 >> Val...@li... >> 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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Mogens L. L. <ML...@ba...> - 2010-04-13 19:58:43
|
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 <go...@mc...> 13-04-2010 17:39 To Dave Goodell <go...@mc...> cc val...@li..., Mogens Lindholdt Lauridsen <ML...@ba...> 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...@gn.../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 >> Val...@li... >> 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 > Val...@li... > 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 Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dave G. <go...@mc...> - 2010-04-13 20:50:57
|
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 <go...@mc...> > 13-04-2010 17:39 > > To > Dave Goodell <go...@mc...> > cc > val...@li..., Mogens Lindholdt Lauridsen <ML...@ba... > > > 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...@gn.../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 > >> Val...@li... > >> 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 > > Val...@li... > > 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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > |
|
From: Mogens L. L. <ML...@ba...> - 2010-04-13 20:57:45
|
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 <go...@mc...>
13-04-2010 22:28
To
Mogens Lindholdt Lauridsen <ML...@ba...>
cc
val...@li...
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 <go...@mc...>
> 13-04-2010 17:39
>
> To
> Dave Goodell <go...@mc...>
> cc
> val...@li..., Mogens Lindholdt Lauridsen
<ML...@ba...
> >
> 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...@gn.../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
> >> Val...@li...
> >> 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
> > Val...@li...
> > 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
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
|
|
From: Dave G. <go...@mc...> - 2010-04-13 21:59:14
|
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 <go...@mc...> > 13-04-2010 22:28 > > To > Mogens Lindholdt Lauridsen <ML...@ba...> > cc > val...@li... > 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 <go...@mc...> > > 13-04-2010 17:39 > > > > To > > Dave Goodell <go...@mc...> > > cc > > val...@li..., Mogens Lindholdt Lauridsen <ML...@ba... > > > > > 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...@gn.../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 > > >> Val...@li... > > >> 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 > > > Val...@li... > > > 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 > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > > > > > |
|
From: Mogens L. L. <ML...@ba...> - 2010-04-14 11:17:04
|
First of all... I don't know what went wrong, but I apparently didn't have your patch in the valgrind binary when I ran that test. Sorry. I have now tried your test program without valgrind, and it hits an assert: # ./dcbzl dcbzl: dcbzl.c:38: main: Assertion `block[(128)+i] == 0x00' failed. Aborted # It seems like the PPC core I use (e300c4) handle dcbzl in another way. It only clears 32 bytes and not 128 as on your PPC970. A college of mine found this comment in FFMpeg code (libavcodec/ppc/dsputil_ppc.c): /* ***** WARNING ***** WARNING ***** WARNING ***** */ /* clear_blocks_dcbz32_ppc will not work properly on PowerPC processors with a cache line size not equal to 32 bytes. Fortunately all processor used by Apple up to at least the 7450 (aka second generation G4) use 32 bytes cache line. This is due to the use of the 'dcbz' instruction. It simply clear to zero a single cache line, so you need to know the cache line size to use it ! It's absurd, but it's fast... update 24/06/2003 : Apple released yesterday the G5, with a PPC970. cache line size: 128 bytes. Oups. The semantic of dcbz was changed, it always clear 32 bytes. so the function below will work, but will be slow. So I fixed check_dcbz_effect to use dcbzl, which is defined to clear a cache line (as dcbz before). So we still can distinguish, and use dcbz (32 bytes) or dcbzl (one cache line) as required. see <http://developer.apple.com/technotes/tn/tn2087.html> and <http://developer.apple.com/technotes/tn/tn2086.html> */ The page http://developer.apple.com/legacy/mac/library/technotes/tn/tn2087.html explains it quite well. I have looked at the FFMpeg code and they run the dcbzl instruction and checks how it works, to see if they can use it. So I have changed your test program so the BLOCK_SIZE is 32. And now the program can run on my target. However valgrind crashed because of the "vassert(lineszB == 128);" in you patch. I have also changed this, and now it works! -Mogens Dave Goodell <go...@mc...> 14-04-2010 00:01 To Mogens Lindholdt Lauridsen <ML...@ba...> cc val...@li... Subject Re: [Valgrind-users] PPC: unhandled instruction: 0x7C2907EC 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 <go...@mc...> > 13-04-2010 22:28 > > To > Mogens Lindholdt Lauridsen <ML...@ba...> > cc > val...@li... > 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 <go...@mc...> > > 13-04-2010 17:39 > > > > To > > Dave Goodell <go...@mc...> > > cc > > val...@li..., Mogens Lindholdt Lauridsen <ML...@ba... > > > > > 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...@gn.../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 > > >> Val...@li... > > >> 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 > > > Val...@li... > > > 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 > > Val...@li... > > 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 Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dave G. <go...@mc...> - 2010-04-14 17:35:00
|
On Apr 14, 2010, at 6:01 AM, Mogens Lindholdt Lauridsen wrote: > First of all... I don't know what went wrong, but I apparently > didn't have your patch in the valgrind binary when I ran that test. > Sorry. No worries, it's easy to do. > I have now tried your test program without valgrind, and it hits an > assert: > # ./dcbzl > dcbzl: dcbzl.c:38: main: Assertion `block[(128)+i] == 0x00' failed. > Aborted > # > > It seems like the PPC core I use (e300c4) handle dcbzl in another > way. It only clears 32 bytes and not 128 as on your PPC970. A > college of mine found this comment in FFMpeg code (libavcodec/ppc/ > dsputil_ppc.c): [...] > The page http://developer.apple.com/legacy/mac/library/technotes/tn/tn2087.html > explains it quite well. > > I have looked at the FFMpeg code and they run the dcbzl instruction > and checks how it works, to see if they can use it. That may not be a valid instruction for your particular processor. I was working under the assumption that you were using a PPC970. Does my test program run correctly *outside* of valgrind, or does it give you a SIGILL? This page discusses dcbz versus dcbzl: http://www.powerdeveloper.org/forums/viewtopic.php?p=9842&sid=b54491befbf4ec2df4844d4d09657ddb#9842 My PPC970 user manual generally agrees with that comment. Since the only difference between a dcbz and dcbzl is that bit 10 (in PPC-manual-speak, bit 21 in normal/VEX numbering) is 0/1, it may be that your e300 core is just ignoring that bit. However those bits (PPC:6-10 / VEX:25-21) are reserved, which means they can result in boundedly undefined behavior if they aren't zeroed. See pages 111 ("Boundedly Undefined") and 358 ("dcbz encoding") of the e300 manual: http://www.freescale.com/files/32bit/doc/ref_manual/e300coreRM.pdf > So I have changed your test program so the BLOCK_SIZE is 32. And now > the program can run on my target. However valgrind crashed because > of the "vassert(lineszB == 128);" in you patch. > I have also changed this, and now it works! I'm glad this gets you unstuck, but I think that assertion (or perhaps a more informative error message) is still appropriate for the dcbzl instruction. I think that FFMpeg shouldn't be using that instruction on older/embedded PPC processors. But as I said before, I'm far from being a PPC expert, so I could be totally wrong on this. I also don't know what the typical valgrind/ VEX behavior is in these cases of minor platform variation. I would guess that it tries to "do the right thing" most of the time, which in this case would be to just zero the cache line size given by lineszB. This is especially true if most/all non-970 processors ignore those reserved bits. -Dave |
|
From: Mogens L. L. <ML...@ba...> - 2010-04-14 21:33:38
|
>That may not be a valid instruction for your particular processor. I >was working under the assumption that you were using a PPC970. Does >my test program run correctly *outside* of valgrind, or does it give >you a SIGILL? If I change the BLOCK_SIZE from 128 to 32, your test program runs fine on my CPU. I will investigate this is pure luck, or dcbzl really is supported. I will also take a deeper look into how FFmpeg is handling/using this instruction. Thanks very much for your help so far! -Mogens Dave Goodell <go...@mc...> 14-04-2010 19:35 To Mogens Lindholdt Lauridsen <ML...@ba...> cc val...@li... Subject Re: [Valgrind-users] PPC: unhandled instruction: 0x7C2907EC On Apr 14, 2010, at 6:01 AM, Mogens Lindholdt Lauridsen wrote: > First of all... I don't know what went wrong, but I apparently > didn't have your patch in the valgrind binary when I ran that test. > Sorry. No worries, it's easy to do. > I have now tried your test program without valgrind, and it hits an > assert: > # ./dcbzl > dcbzl: dcbzl.c:38: main: Assertion `block[(128)+i] == 0x00' failed. > Aborted > # > > It seems like the PPC core I use (e300c4) handle dcbzl in another > way. It only clears 32 bytes and not 128 as on your PPC970. A > college of mine found this comment in FFMpeg code (libavcodec/ppc/ > dsputil_ppc.c): [...] > The page http://developer.apple.com/legacy/mac/library/technotes/tn/tn2087.html > explains it quite well. > > I have looked at the FFMpeg code and they run the dcbzl instruction > and checks how it works, to see if they can use it. That may not be a valid instruction for your particular processor. I was working under the assumption that you were using a PPC970. Does my test program run correctly *outside* of valgrind, or does it give you a SIGILL? This page discusses dcbz versus dcbzl: http://www.powerdeveloper.org/forums/viewtopic.php?p=9842&sid=b54491befbf4ec2df4844d4d09657ddb#9842 My PPC970 user manual generally agrees with that comment. Since the only difference between a dcbz and dcbzl is that bit 10 (in PPC-manual-speak, bit 21 in normal/VEX numbering) is 0/1, it may be that your e300 core is just ignoring that bit. However those bits (PPC:6-10 / VEX:25-21) are reserved, which means they can result in boundedly undefined behavior if they aren't zeroed. See pages 111 ("Boundedly Undefined") and 358 ("dcbz encoding") of the e300 manual: http://www.freescale.com/files/32bit/doc/ref_manual/e300coreRM.pdf > So I have changed your test program so the BLOCK_SIZE is 32. And now > the program can run on my target. However valgrind crashed because > of the "vassert(lineszB == 128);" in you patch. > I have also changed this, and now it works! I'm glad this gets you unstuck, but I think that assertion (or perhaps a more informative error message) is still appropriate for the dcbzl instruction. I think that FFMpeg shouldn't be using that instruction on older/embedded PPC processors. But as I said before, I'm far from being a PPC expert, so I could be totally wrong on this. I also don't know what the typical valgrind/ VEX behavior is in these cases of minor platform variation. I would guess that it tries to "do the right thing" most of the time, which in this case would be to just zero the cache line size given by lineszB. This is especially true if most/all non-970 processors ignore those reserved bits. -Dave |