|
From: Sebastien C. <seb...@ya...> - 2010-04-14 20:53:04
|
Hi, Running memcheck on my application which is using the Intel Performance Primitive library doesn't work because of some unhandled instructions. I opened bug 233638 to track the problem. ( http://bugs.kde.org/show_bug.cgi?id=233638 ) I would really like to get valgrind to run on that application to help tracking memory leaks, but I really don't know where to start. Is there a document that describes how to add support for new instructions? I wouldn't mind if valgrind just skipped these instructions without checking for memory errors. Any help would be appreciated. Sebastien __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ |
|
From: Philippe W. <phi...@sk...> - 2010-04-15 06:30:22
|
> Is there a document that describes how to add support for new instructions? I wouldn't mind if valgrind just skipped these
> instructions without checking for memory errors.
>
> Any help would be appreciated.
I do not know if there is a document explaining all that but maybe the easiest is to take
one of the recent patches that have added an instruction and mimick that ?
e.g. an instruction was added by the following 2 posts to valgrind dev
[Valgrind-developers] vex: r1971 - trunk/priv
[Valgrind-developers] vex: r1972 - trunk/priv
Philippe
|
|
From: Sebastien C. <seb...@ya...> - 2010-04-15 19:56:29
|
Hi,
It seems the instructions were already handled in VEX but not with the REX prefix. I tried changing the code to work around it like the following:
/* 66 0F FC = PADDB */
- if (have66noF2noF3(pfx) && sz == 2
+ if ((have66noF2noF3(pfx) || haveREX(pfx))
+ && (sz == 2 || /* ignore redundant REX.W */ sz == 8)
&& insn[0] == 0x0F && insn[1] == 0xFC) {
delta = dis_SSEint_E_to_G( vbi, pfx, delta+2,
"paddb", Iop_Add8x16, False );
I may have broken something with this change but it got rid of the previous unhandled instructions. However, now I get an unhandled instruction on:
66 48 0f d7 c0 pmovmskb %xmm0,%rax
Now I really don't know how to work around this because the handling of the pmovmskb instruction is much more complex than the previous ones.
Thanks,
Sebastien
--- On Thu, 4/15/10, Philippe Waroquiers <phi...@sk...> wrote:
> From: Philippe Waroquiers <phi...@sk...>
> Subject: Re: [Valgrind-developers] Unhandled instruction on x86-64
> To: val...@li...
> Received: Thursday, April 15, 2010, 2:30 AM
> > Is there a document that
> describes how to add support for new instructions? I
> wouldn't mind if valgrind just skipped these
> > instructions without checking for memory errors.
> >
> > Any help would be appreciated.
> I do not know if there is a document explaining all that
> but maybe the easiest is to take
> one of the recent patches that have added an instruction
> and mimick that ?
>
> e.g. an instruction was added by the following 2 posts to
> valgrind dev
> [Valgrind-developers] vex: r1971 -
> trunk/priv
> [Valgrind-developers] vex: r1972 -
> trunk/priv
>
> Philippe
>
>
> ------------------------------------------------------------------------------
> 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-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|
|
From: Julian S. <js...@ac...> - 2010-04-16 20:32:54
|
On Thursday 15 April 2010, Sebastien Cote wrote:
> Hi,
>
> It seems the instructions were already handled in VEX but not with the REX
> prefix. I tried changing the code to work around it like the following:
>
> /* 66 0F FC = PADDB */
> - if (have66noF2noF3(pfx) && sz == 2
> + if ((have66noF2noF3(pfx) || haveREX(pfx))
> + && (sz == 2 || /* ignore redundant REX.W */ sz == 8)
> && insn[0] == 0x0F && insn[1] == 0xFC) {
> delta = dis_SSEint_E_to_G( vbi, pfx, delta+2,
> "paddb", Iop_Add8x16, False );
>
>
> I may have broken something with this change but it got rid of the previous
> unhandled instructions. However, now I get an unhandled instruction on:
That's nearly right. In fact the "haveREX(pfx)" is redundant, so in fact
the only change is from
sz == 2
to
(sz == 2 || /* ignore redundant REX.W */ sz == 8)
> 66 48 0f d7 c0 pmovmskb %xmm0,%rax
>
> Now I really don't know how to work around this because the handling of the
> pmovmskb instruction is much more complex than the previous ones.
I'm surprised it failed there. It looks to me like the handler for pmovmskb
(xmm version), around line 11860 of guest_am64_toIR.c, can handle the
redundant rex prefix (0x48).
J
|
|
From: Sebastien C. <seb...@ya...> - 2010-04-17 14:49:49
|
Hi Julien, Thank you for your answer. It seems that only adding the support for "sz == 8" doesn't work. If I remove the "haveREX(pfx)" from my change then it fails. For the PMOVMSKB instruction, I changed the code to return success if the "epartIsReg(modrm)" check fails. I'm pretty sure this change broke something but now I can run my application inside valgrind with memcheck and memory leaks are detected correctly. I attached the diff for my changes to the bug ( http://bugs.kde.org/show_bug.cgi?id=233638 ). If you have suggestions for a correct fix, I'm willing to try them. Sebastien --- On Fri, 4/16/10, Julian Seward <js...@ac...> wrote: > From: Julian Seward <js...@ac...> > Subject: Re: [Valgrind-developers] Unhandled instruction on x86-64 > To: val...@li... > Cc: "Sebastien Cote" <seb...@ya...> > Received: Friday, April 16, 2010, 4:48 PM > On Thursday 15 April 2010, Sebastien > Cote wrote: > > Hi, > > > > It seems the instructions were already handled in VEX > but not with the REX > > prefix. I tried changing the code to work around it > like the following: > > > > /* 66 0F FC = PADDB */ > > - if (have66noF2noF3(pfx) && > sz == 2 > > + if ((have66noF2noF3(pfx) || > haveREX(pfx)) > > + && (sz == 2 > || /* ignore redundant REX.W */ sz == 8) > > && > insn[0] == 0x0F && insn[1] == 0xFC) { > > delta = dis_SSEint_E_to_G( > vbi, pfx, delta+2, > > > > "paddb", Iop_Add8x16, False ); > > > > > > I may have broken something with this change but it > got rid of the previous > > unhandled instructions. However, now I get an > unhandled instruction on: > > That's nearly right. In fact the "haveREX(pfx)" is > redundant, so in fact > the only change is from > > sz == 2 > > to > > (sz == 2 || /* ignore redundant REX.W */ > sz == 8) > > > > 66 48 0f d7 c0 > pmovmskb %xmm0,%rax > > > > Now I really don't know how to work around this > because the handling of the > > pmovmskb instruction is much more complex than the > previous ones. > > I'm surprised it failed there. It looks to me like > the handler for pmovmskb > (xmm version), around line 11860 of guest_am64_toIR.c, can > handle the > redundant rex prefix (0x48). > > J > |