zenithsiz/ftmemsim-valgrind
1
0
Fork 0
mirror of https://github.com/Zenithsiz/ftmemsim-valgrind.git synced 2026-02-04 02:18:37 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

PR432809 VEX should support REX.W + POPF

Browse Source 
It seems a REX.W prefix simply explicitly sets the operant size to 8,
and so can/must be ignored as redundant. This is what we already do
for PUSH, POP and PUSHF. All instructions are described as "When in
64-bit mode, instruction defaults to 64-bit operand size and cannot
encode 32-bit operand size." in the instruction manual.

Original patch and analysis by Mike Dalessio <mike.dalessio@gmail.com>

https://bugs.kde.org/show_bug.cgi?id=432809
This commit is contained in:
Mark Wielaard 2021-02-12 20:42:00 +01:00
parent b4eff82004
commit e2e830f612
2 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
NEWS
View File

@ -88,6 +88,7 @@ n-i-bz helgrind: If hg_cli__realloc fails, return NULL.
430354 ppc stxsibx and stxsihx instructions write too much data
430485 expr_is_guardable doesn't handle Iex_Qop
432672 vg_regtest: test-specific environment variables not reset between tests
432809 VEX should support REX.W + POPF
432861 PPC modsw and modsd give incorrect results for 1 mod 12
Release 3.16.1 (?? June 2020)

2
VEX/priv/guest_amd64_toIR.c
View File

@ -20586,7 +20586,7 @@ Long dis_ESC_NONE (
/* Note. There is no encoding for a 32-bit popf in 64-bit mode.
So sz==4 actually means sz==8. */
if (haveF2orF3(pfx)) goto decode_failure;
vassert(sz == 2 || sz == 4);
vassert(sz == 2 || sz == 4 || sz == 8);
if (sz == 4) sz = 8;
if (sz != 8) goto decode_failure; // until we know a sz==2 test case exists
t1 = newTemp(Ity_I64); t2 = newTemp(Ity_I64);