https://bugs.kde.org/show_bug.cgi?id=465213
Bug ID: 465213
Summary: x86 tzcnt/lzcnt are incorrectly handled
Classification: Developer tools
Product: valgrind
Version: 3.21 GIT
Platform: unspecified
OS: All
Status: REPORTED
Severity: normal
Priority: NOR
Component: vex
Assignee: jsew...@acm.org
Reporter: parkj...@kaist.ac.kr
Target Milestone: ---
commit `7003f40be9de1e10796578cba9e40ea6a548fc16` (current latest)
```c
// VEX/priv/guest_x86_toIR.c:14270
switch (abyte) {
case 0x0F:
switch (getIByte(delta)) {
/* On older CPUs, TZCNT behaves the same as BSF. */
case 0xBC: /* REP BSF Gv,Ev */
delta = dis_bs_E_G ( sorb, sz, delta + 1, True );
break;
/* On older CPUs, LZCNT behaves the same as BSR. */
case 0xBD: /* REP BSR Gv,Ev */
delta = dis_bs_E_G ( sorb, sz, delta + 1, False );
break;
default:
goto decode_failure;
}
break;
```
In x86, `tzcnt` behaves not the same with `bsf`, and `lzcnt` behaves not the
same with `bsr`. For operands that have values of 0, `tzcnt` and `lzcnt` give
results of 0x20, while `bsf` and `bsr` give results of 0.
You can refer to https://www.felixcloutier.com/x86/tzcnt and
https://www.felixcloutier.com/x86/lzcnt .
> The key difference between TZCNT and BSF instruction is that TZCNT provides
> operand size as output when source operand is zero while in the case of BSF
> instruction, if source operand is zero, the content of destination operand
> are
> undefined.
> LZCNT differs from BSR. For example, LZCNT will produce the operand size
> when the input operand is zero.
I saw this problematic when I was lifting `tzcnt` and `lzcnt` with pyvex. I'm
not sure if the code is the correct place to fix.
--
You are receiving this mail because:
You are watching all bug changes.
