x86-64-branch-3 test case

[H.J. Lu]

On Fri, Dec 13, 2019 at 9:02 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 13.12.2019 17:09,  H.J. Lu  wrote:
> > 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?
>
> I did mean "prefix" (the data16 one). And yes, it'll permit the
> m16:m64 form, just like LFS et al already allow.
>
> >> 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.
>
> lcallq / ljmpq will be the obvious mnemonics to use for AT&T mode.
> I didn't even think there was any question in this regard.
>

Please put your proposed syntax in the bug report.   On the other
hand, I don't think it will get much use.


-- 
H.J.