Re: x86-64-branch-3 test case

[Jan Beulich <jbeulich at suse dot com>]

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.)

Jan