Re: [Valgrind-users] Apparent bug in svn head

[Eliot M. <mo...@cs...>]

On 2/4/2012 7:02 AM, Julian Seward wrote:
>
>> I did that, but when I run the updated valgrind on
>> the same program as before (Oracle's HotSpot JVM),
>> it fails on a 0xF 0xAE 0x3F instruction, which
>> appears to be either a CLFLUSH or an SFENCE (both
>> decode the same way in the docs, so I am slightly
>> confused).  Either way, it worked in the latest
>> stable release, and I didn't mess with that decoding.
>
> There was a massive overhaul lately of the x86_64 instruction
> decoding (a new framework) and insns were only added back into the
> new framework when test cases appeared (iow, on demand).  A few
> didn't make it back in yet due to no test case, and CLFLUSH at
> least is amongst them.  The old versions are #if 0'd out at the
> bottom of guest_amd64_toIR.c.
>
> I'd appreciate if you can find the right place for the ones you
> have fallen over and send a patch accordingly.  You'll need to figure
> out which of dis_ESC_NONE, _ESC_0F, _ESC_0F38, _ESC_0F3A you need
> to put it/them in, based on which what escape bytes (0F, 0F38, 0F3A, or
> none) precede the main opcode.

Thanks, and I clarified that it is indeed clflush. I am now
straight about mod/rm encoding :-) . I have added clflush
back, in dis_0F__SSE2.  Since clflush uses the DisResult, I had
the modify dis_0F__SSE2 to receive the DisResult* as an argument,
and modify its caller to pass it. I am running tests now.

This would be a good time to ask about how to prepare and send
patches, i.e., what you want for these (re)additions.

Regards -- Eliot