Hi! I have found a bug in the x86 instruction semantics, where the wrong destination register is used.
A test case is vpshufd ymm6, ymmword ptr [rip + 0xe98134a], 0x26:
bap mc --show-insn=pretty --show-bil=pretty C5FD70354A13980E26
Which prints:
VPSHUFDYmi(YMM6,RIP,0x1,Nil,0xe98134a,Nil,0x26)
{
YMM0 := low:32[mem[0xE981353, el]:u256 >>
0x80].low:32[mem[0xE981353, el]:u256 >>
0xC0].low:32[mem[0xE981353, el]:u256 >>
0xA0].low:32[mem[0xE981353, el]:u256 >>
0xC0].low:32[mem[0xE981353, el]:u256].low:32[mem[0xE981353, el]:u256 >>
0x40].low:32[mem[0xE981353, el]:u256 >>
0x20].low:32[mem[0xE981353, el]:u256 >> 0x40]
}
This is incorrect: the instruction should write to YMM6 instead of YMM0.
I suspect this might be related to this code in x86_lifter.ml:
(match vsrc with
| None -> [assn t dst dwords]
| Some vdst -> [assn t vdst dwords])
If desired, I can look into this more and try to work on a patch.
Hi! I have found a bug in the x86 instruction semantics, where the wrong destination register is used.
A test case is
vpshufd ymm6, ymmword ptr [rip + 0xe98134a], 0x26:Which prints:
This is incorrect: the instruction should write to YMM6 instead of YMM0.
I suspect this might be related to this code in
x86_lifter.ml:If desired, I can look into this more and try to work on a patch.