aboutsummaryrefslogtreecommitdiff
path: root/libiberty/pex-win32.c
diff options
context:
space:
mode:
authorJan Beulich <jbeulich@suse.com>2020-02-14 14:27:28 +0100
committerJan Beulich <jbeulich@suse.com>2020-02-14 14:27:28 +0100
commit65fca0597f3a5f76f6d7d79bc3a922c160254e0a (patch)
tree52ea7653991780e22ee475a6963e8d29a2fe72c6 /libiberty/pex-win32.c
parentb6773884364e0275a793adad4b025913fa155d5a (diff)
downloadgdb-65fca0597f3a5f76f6d7d79bc3a922c160254e0a.zip
gdb-65fca0597f3a5f76f6d7d79bc3a922c160254e0a.tar.gz
gdb-65fca0597f3a5f76f6d7d79bc3a922c160254e0a.tar.bz2
x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX
For these to get treatment consistent with other operand size checking the special logic shouldn't live in md_assemble(), but process_suffix(). And there's more logic involved than simply zapping the suffix. Note however that MOVS[BW]* and MOVZ[BW]* still won't be fully consistent, due to the objection to fold MOVS* templates just like was done for MOVZ* in c07315e0c6 ("x86: allow suffix-less movzw and 64-bit movzb"). Note further that it is against my own intentions to have MOVSX/MOVZX silently default to a byte source in AT&T mode. This should happen only when the destination register is a 16-bit one. In all other cases there is an ambiguity, and the user should be warned. But it was explicitly requested for this to be done in a way inconsistent with everything else. Note finally that the assembler change points out (and this patch fixes) a wrong Intel syntax test introduced by bc31405ebb2c ("x86-64: Properly encode and decode movsxd"): When source code specifies a 16-bit destination register, disassembly expectations shouldn't have been to find a 32-bit one.
Diffstat (limited to 'libiberty/pex-win32.c')
0 files changed, 0 insertions, 0 deletions