|
From: Steve B. <ste...@gm...> - 2012-02-25 21:10:27
|
I should've mentioned of course that I'm using 3.8.0-SVN, checked out about a week ago (at home now so I cannot check the exact revision number right now). In any case, the fresh air on the walk home made me think: 0x000000000616aeee <+606>: prefetchw BYTE PTR [rdi+0x340] The prefetchw instruction doesn't sound as something common to me, so I would not be surprised if it is not implemented in Callgrind/LibVex. I can't explain yet why that instruction is hit only with certain data though. Is there an 'implemented instructions' list available for LibVex ? Thanks |
|
From: Eliot M. <mo...@cs...> - 2012-02-25 21:41:15
|
On 2/25/2012 4:10 PM, Steve Burden wrote: > > I should've mentioned of course that I'm using 3.8.0-SVN, checked out about a week ago (at home now > so I cannot check the exact revision number right now). > > In any case, the fresh air on the walk home made me think: > 0x000000000616aeee <+606>: prefetchw BYTE PTR [rdi+0x340] > The prefetchw instruction doesn't sound as something common to me, so I would not be surprised if it > is not implemented in Callgrind/LibVex. > I can't explain yet why that instruction is hit only with certain data though. > > Is there an 'implemented instructions' list available for LibVex ? I had checked and it looks as if guest_amd64_toIR implements this case (parsing the guest instruction, but generating no IR for it, since it is *semantically* a no-op). I don't understand why it fails unless if was added since you checked out from SVN. Best wishes -- Eliot Moss |
|
From: Philippe W. <phi...@sk...> - 2012-02-26 10:32:00
|
On Sat, 2012-02-25 at 22:10 +0100, Steve Burden wrote:
>
> I should've mentioned of course that I'm using 3.8.0-SVN, checked out
> about a week ago (at home now so I cannot check the exact revision
> number right now).
>
>
> In any case, the fresh air on the walk home made me think:
> 0x000000000616aeee <+606>: prefetchw BYTE PTR [rdi+0x340]
> The prefetchw instruction doesn't sound as something common to me, so
> I would not be surprised if it is not implemented in Callgrind/LibVex.
> I can't explain yet why that instruction is hit only with certain data
> though.
>
>
> Is there an 'implemented instructions' list available for LibVex ?
I guess the only way for this is to look at guest_amd64_toIR.c
It looks like that prefetchw instruction should be supported
(see below extract of the code).
What you could do is to replace the 'goto decode_failure'
with {
VG_(printf) ("describe decode failure here\n");
goto decode_failure;
}
then run and see why it cannot be decoded.
You might also put Valgrind in gdb (see README_DEVELOPPERS),
and put breaks on the VG_(printf).
Philippe
/* =-=-=-=-=-=-=-=-=- PREFETCH =-=-=-=-=-=-=-=-=-= */
case 0x0D: /* 0F 0D /0 -- prefetch mem8 */
/* 0F 0D /1 -- prefetchw mem8 */
if (have66orF2orF3(pfx)) goto decode_failure;
modrm = getUChar(delta);
if (epartIsReg(modrm)) goto decode_failure;
if (gregLO3ofRM(modrm) != 0 && gregLO3ofRM(modrm) != 1)
goto decode_failure;
addr = disAMode ( &alen, vbi, pfx, delta, dis_buf, 0 );
delta += alen;
switch (gregLO3ofRM(modrm)) {
case 0: DIP("prefetch %s\n", dis_buf); break;
case 1: DIP("prefetchw %s\n", dis_buf); break;
default: vassert(0); /*NOTREACHED*/
}
break;
|
|
From: Steve B. <ste...@gm...> - 2012-02-26 11:57:38
|
> I don't understand why it fails unless if was added since you checked
out from SVN.
Ok apparently there have been some changes to the guest_amd64_toIR.c file
since I checked out, everything runs fine with the HEAD revision :).
Apologies for not having tested this, but what are the chances that my
problem got fixed in the last week right ;).
Thank you Eliot and Philippe for your time.
Steve
On Sun, Feb 26, 2012 at 11:32 AM, Philippe Waroquiers <
phi...@sk...> wrote:
> On Sat, 2012-02-25 at 22:10 +0100, Steve Burden wrote:
> >
> > I should've mentioned of course that I'm using 3.8.0-SVN, checked out
> > about a week ago (at home now so I cannot check the exact revision
> > number right now).
> >
> >
> > In any case, the fresh air on the walk home made me think:
> > 0x000000000616aeee <+606>: prefetchw BYTE PTR [rdi+0x340]
> > The prefetchw instruction doesn't sound as something common to me, so
> > I would not be surprised if it is not implemented in Callgrind/LibVex.
> > I can't explain yet why that instruction is hit only with certain data
> > though.
> >
> >
> > Is there an 'implemented instructions' list available for LibVex ?
> I guess the only way for this is to look at guest_amd64_toIR.c
>
> It looks like that prefetchw instruction should be supported
> (see below extract of the code).
> What you could do is to replace the 'goto decode_failure'
> with {
> VG_(printf) ("describe decode failure here\n");
> goto decode_failure;
> }
> then run and see why it cannot be decoded.
> You might also put Valgrind in gdb (see README_DEVELOPPERS),
> and put breaks on the VG_(printf).
>
> Philippe
>
>
>
> /* =-=-=-=-=-=-=-=-=- PREFETCH =-=-=-=-=-=-=-=-=-= */
> case 0x0D: /* 0F 0D /0 -- prefetch mem8 */
> /* 0F 0D /1 -- prefetchw mem8 */
> if (have66orF2orF3(pfx)) goto decode_failure;
> modrm = getUChar(delta);
> if (epartIsReg(modrm)) goto decode_failure;
> if (gregLO3ofRM(modrm) != 0 && gregLO3ofRM(modrm) != 1)
> goto decode_failure;
>
> addr = disAMode ( &alen, vbi, pfx, delta, dis_buf, 0 );
> delta += alen;
>
> switch (gregLO3ofRM(modrm)) {
> case 0: DIP("prefetch %s\n", dis_buf); break;
> case 1: DIP("prefetchw %s\n", dis_buf); break;
> default: vassert(0); /*NOTREACHED*/
> }
> break;
>
>
>
>
|
|
From: Julian S. <js...@ac...> - 2012-03-02 12:14:32
|
On Sunday, February 26, 2012, Steve Burden wrote: > > I don't understand why it fails unless if was added since you checked > > out from SVN. > > Ok apparently there have been some changes to the guest_amd64_toIR.c file > since I checked out, everything runs fine with the HEAD revision :). Are you sure about this? What I think has happened is that these insns have in fact been supported for a long time, but temporarily got disabled as part of a restructuring of guest_amd64_toIR.c that happened about a month back. And they have not been re-enabled yet. Could you re-test the trunk (the HEAD revision, I mean) ? If you can repro the failure on trunk then I can fix it properly, which would be a good thing to do. J |