This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]