Re: x86-64-branch-3 test case

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Dec 13, 2019 at 1:39 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> H.J.,
>
> in the course of addressing bug 24546 I'd once again stumbled across
> this test, and in particular its entirely wrong expectations (aiui):
> The notation "jmp symbol" expresses a direct jump, not an indirect
> one. Adding any kind of prefix should not alter this. And a near
> branch ("jmp" doesn't stand for far ones in AT&T syntax) should in
> no case then even become a far branch encoding. Imo the correct
> course of action by the assembler would be to either warn about
> and drop the bogus (in Intel64 mode) prefix, or keep it as benign,
> but still emit a direct branch encoding with a 32-bit displacement.

Did you mean "suffix"?  Will it implement m16:m64 in 64-bit mode
for Intel64?

> Thoughts?
>
> For background: These are the intended new templates:
>
> // Intel Syntax remaining jmp instances.
> jmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
> jmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Unspecified|BaseIndex }
> jmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Tbyte|Unspecified|BaseIndex }
> ljmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
> ljmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex }
> ljmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }
>
> It's the Cpu64 here which causes things to break: i386-gen infers
> no Disp16 in this case from BaseIndex, and hence the Disp16
> generated in i.types[0] won't match in Intel64 mode (but as said
> above imo there shouldn't have been a match even before my
> changes). And of course i386_displacement() has its own issues
> when considering the case of us assuming (with a warning) an
> indirect branch even when not indicated so by '*' if no better
> match can be found.
>
> I assume it goes without saying that once I make the Cpu64 case
> work correctly here, and if not going the match-the-direct-jmp
> route as suggested above, the match would then be with the near
> indirect jmp (which right now doesn't match just because of it
> having Cpu64 on its template, as per above). IOW the generated
> code here will change no matter what.
>

If we want to support m16:m64 for Intel64, what syntax do we want
to use in AT&T syntax?  If it makes assembler more complex, we
should leave it alone since it doesn't bring much benefit.

Thanks.

-- 
H.J.