|
From: Amstoutz M. <Mar...@th...> - 2012-06-04 17:23:30
|
Hi valgrind experts, I'm facing an unhandled instruction issue when valgrinding ing intel-ipp libraries. ~/valgrind-3.7.0/bin/valgrind --tool=memcheck --leak-check=full --show-reachable=yes --error-limit=no --log-file=valgrnd.txt --gen-suppressions=all ... vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xFC 0xD 0x37 0xBB 0x22 0x0 ==12078== valgrind: Unrecognised instruction at address 0x4cacf71. ==12078== at 0x4CACF71: ??? (in ...) ==12078== by 0x4CA3282: y8_ippiFilterDeblockingLuma_VerEdge_H264_8u_C1IR (in ...) I have tried to disable error reporting using VALGRIND_DISABLE_ERROR_REPORTING/ VALGRIND_ENABLE_ERROR_REPORTING macros without success. Could you help me to disable error reporting for this error ? In addition, do you think such error should be reported as a bug (I've noticed similar bugs into the bugbase) ? Regards, Marc |
|
From: Eliot M. <mo...@cs...> - 2012-06-04 17:32:33
|
On 6/4/2012 1:23 PM, Amstoutz Marc wrote: > Hi valgrind experts, > > I’m facing an unhandled instruction issue when valgrinding ing intel-ipp libraries. > > ~/valgrind-3.7.0/bin/valgrind --tool=memcheck --leak-check=full --show-reachable=yes > --error-limit=no --log-file=valgrnd.txt --gen-suppressions=all … > > vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xFC 0xD 0x37 0xBB 0x22 0x0 > > ==12078== valgrind: Unrecognised instruction at address 0x4cacf71. > > ==12078== at 0x4CACF71: ??? (in …) > > ==12078== by 0x4CA3282: y8_ippiFilterDeblockingLuma_VerEdge_H264_8u_C1IR (in …) > > I have tried to disable error reporting using VALGRIND_DISABLE_ERROR_REPORTING/ > VALGRIND_ENABLE_ERROR_REPORTING macros without success. > > Could you help me to disable error reporting for this error ? > > In addition, do you think such error should be reported as a bug (I’ve noticed similar bugs into the > bugbase) ? Dear Marc -- You can't disable that. It means that valgrind encountered instructions that it does not know what to do with. There is no way for it to continue sensibly (beyond causing a signal, which presumably is unhandled here). A quick look suggests that this is a PADDB instruction. I think someone has been working on adding some of those instructions latelt; it *might* be covered if you grab and build from svn head. Regards -- Eliot Moss (a fellow user and occasional patch contributor) |
|
From: Julian S. <js...@ac...> - 2012-06-05 00:50:10
|
On Monday, June 04, 2012, Eliot Moss wrote:
> unhandled here). A quick look suggests that this is a PADDB instruction.
Yes, 64-bit (MMX) PADDB. Problem is it has a redundant REX prefix
(IPP is very strong on those, for some reason), and Valgrind pretty
much rejects all redundant REX prefixes.
Marc, in guest_amd64_toIR.c find this
case 0xFC:
case 0xFD:
case 0xFE: /* PADDgg (src)mmxreg-or-mem, (dst)mmxreg */
if (sz != 4)
goto mmx_decode_failure;
delta = dis_MMXop_regmem_to_reg ( vbi, pfx, delta, opc, "padd", True
);
break;
and change (sz != 4) to (sz != 4 && sz != 8). That might help.
J
> I think someone has been working on adding some of those instructions
> latelt; it *might* be covered if you grab and build from svn head.
>
> Regards -- Eliot Moss (a fellow user and occasional patch contributor)
>
> ---------------------------------------------------------------------------
> --- Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Amstoutz M. <Mar...@th...> - 2012-06-07 14:09:05
|
Hi Julian,
Pleased to get an answer from the original author of Valgrind !
The fix you suggested seems to work on my application.
I had to fix the following cases found afterwards.
Could you confirm the fixes are correct ?
Regards,
Marc
vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0x64 0x74 0x1C 0x20 0xF 0xDB
case 0x64:
case 0x65:
case 0x66: /* PCMPGTgg (src)mmxreg-or-mem, (dst)mmxreg */
if (sz != 4 && sz != 8)
goto mmx_decode_failure;
delta = dis_MMXop_regmem_to_reg ( vbi, pfx, delta, opc, "pcmpgt", True );
break;
vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xD7 0xC0 0x48 0x85 0xC0 0xF
/* ***--- this is an MMX class insn introduced in SSE1 ---*** */
/* 0F D7 = PMOVMSKB -- extract sign bits from each of 8 lanes in
mmx(G), turn them into a byte, and put zero-extend of it in
ireg(G). */
if (haveNo66noF2noF3(pfx) && ( sz == 4 || sz == 8 )
&& insn[0] == 0x0F && insn[1] == 0xD7) {
vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xEB 0x7C 0x24 0x60 0xF 0x6F
case 0xEB: /* POR (src)mmxreg-or-mem, (dst)mmxreg */
if (sz != 4 && sz != 8)
goto mmx_decode_failure;
delta = dis_MMXop_regmem_to_reg ( vbi, pfx, delta, opc, "por", False );
break;
-----Message d'origine-----
De : Julian Seward [mailto:js...@ac...]
Envoyé : mardi 5 juin 2012 02:47
À : val...@li...; mo...@cs...
Cc : Amstoutz Marc
Objet : Re: [Valgrind-users] how to disable unhandled instruction bytes error reporting
On Monday, June 04, 2012, Eliot Moss wrote:
> unhandled here). A quick look suggests that this is a PADDB instruction.
Yes, 64-bit (MMX) PADDB. Problem is it has a redundant REX prefix
(IPP is very strong on those, for some reason), and Valgrind pretty
much rejects all redundant REX prefixes.
Marc, in guest_amd64_toIR.c find this
case 0xFC:
case 0xFD:
case 0xFE: /* PADDgg (src)mmxreg-or-mem, (dst)mmxreg */
if (sz != 4)
goto mmx_decode_failure;
delta = dis_MMXop_regmem_to_reg ( vbi, pfx, delta, opc, "padd", True
);
break;
and change (sz != 4) to (sz != 4 && sz != 8). That might help.
J
> I think someone has been working on adding some of those instructions
> latelt; it *might* be covered if you grab and build from svn head.
>
> Regards -- Eliot Moss (a fellow user and occasional patch contributor)
>
> ---------------------------------------------------------------------------
> --- Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|