This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH 1/3] x86-64: fix Intel64 handling of branch with data16 prefix
On 20.12.2019 11:39, Jan Beulich wrote:
> 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 too: 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.
> Once in this area also
> - suppress Disp<N> conversion based on address size prefix when this
> prefix doesn't control the width of the displacement,
> - suppress meaningless setting of Disp32 in logic dealing with just
> 64-bit code,
> - add the missing Disp32S to XBEGIN.
I'm splitting these out into a prereq patch, to address further
anomalies, which then allows e.g. to avoid ...
> --- a/gas/config/tc-i386.c
> +++ b/gas/config/tc-i386.c
> @@ -5885,7 +5885,9 @@ match_template (char mnem_suffix)
> /* Address size prefix will turn Disp64/Disp32/Disp16 operand
> into Disp32/Disp16/Disp32 operand. */
> - if (i.prefix[ADDR_PREFIX] != 0)
> + if (i.prefix[ADDR_PREFIX]
> + && (!t->opcode_modifier.jump
> + || t->opcode_modifier.jump == JUMP_ABSOLUTE))
... having to also check for JUMP_BYTE here. IOW there'll be a
v2 in due course; of course other review comments here are still
appreciated even before this happening.