x86-64-branch-3 test case

[H.J. Lu]

On Mon, Dec 16, 2019 at 2:31 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.12.2019 20:50, H.J. Lu wrote:
> > 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?
>
> May I ask that we make progress with the actual issue at hand, rather
> than discussing the 2nd step before the 1st? The $subject test case is
> definitely bogus (and likely another result of putting in expectations
> matching what the assembler happens to produce at a given point in
> time, rather than having them express how things ought to be, fixing
> the code if need be). The question is which of the two possible
> behaviors we want to go with; for consistency with other code I think
> keeping (emitting) the requested (but ignored by hardware) prefix is
> the better model.
>
> >>>> 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.
>
> I don't understand - what need would there be to have this there,
> the more that it's entirely expected that it would be this way
> (paralleling ljmpw/ljmpl and lcallw/lcalll)? I could understand
> your request if there was something unexpected or counter-
> intuitive to happen. (As to "not much use" - I take it Andrew
> entered the bug for a reason.)
>

GAS has been this way for a long time.  We have a very good
reason to change it.


-- 
H.J.