x86-64: fix Intel64 handling of branch with data16 prefix
authorJan Beulich <jbeulich@suse.com>
Fri, 27 Dec 2019 08:38:34 +0000 (09:38 +0100)
committerJan Beulich <jbeulich@suse.com>
Fri, 27 Dec 2019 08:38:34 +0000 (09:38 +0100)
commit376cd056100dff2d6fc842aa013d0bbffdef363d
tree2fb3cf2b8cfcc1a3fe9cdda133e21fa0e4146377
parent48bcea9f48cce70005307befbc604de3618bbaf7
x86-64: fix Intel64 handling of branch with data16 prefix

The expectation of x86-64-branch-3 for "call" / "jmp" with an obvious
direct destination to translate to an indirect _far_ branch is plain
wrong. The operand size prefix should have no effect at all on the
interpretation of the operand. The main underlying issue here is that
the Intel64 templates of the direct branches don't include Disp16, yet
various assumptions exist that it would always be there when there's
also Disp32/Disp32S, toggled by the operand size prefix (which is
being ignored by direct branches in Intel64 mode).

Along these lines it was also wrong to base the displacement width
decision solely on the operand size prefix: REX.W cancels this effect
and hence needs taking into consideration, too.

A disassembler change is needed here as well: XBEGIN was wrongly treated
the same as direct CALL/JMP, which isn't the case - the operand size
prefix does affect displacement size there, it's merely ignored when it
comes to updating [ER]IP.
gas/ChangeLog
gas/config/tc-i386.c
gas/testsuite/gas/i386/i386.exp
gas/testsuite/gas/i386/x86-64-branch-3.d [new file with mode: 0644]
gas/testsuite/gas/i386/x86-64-branch-3.l [deleted file]
gas/testsuite/gas/i386/x86-64-branch-3.s
opcodes/ChangeLog
opcodes/i386-dis.c
This page took 0.025208 seconds and 4 git commands to generate.