[PATCH v3 10/10] x86-64: Intel64 adjustments for insns dealing with far pointers

[Jan Beulich]

On 15.01.2020 14:28, H.J. Lu wrote:
> On Tue, Jan 14, 2020 at 11:49 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 14.01.2020 18:05, H.J. Lu wrote:
>>> On Tue, Jan 14, 2020 at 7:00 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 13.01.2020 18:42, H.J. Lu wrote:
>>>>> On Fri, Dec 27, 2019 at 1:27 AM Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>
>>>>>> AMD and Intel differ in their handling of far indirect branches as well
>>>>>> as LFS/LGS/LSS: AMD CPUs ignore REX.W while Intel ones honors it. (Note
>>>>>> how the latter three were hybrids so far, while far branches were fully
>>>>>> AMD-like.)
>>>>>>
>>>>>> gas/
>>>>>> 2020-01-XX  Jan Beulich  <jbeulich@suse.com>
>>>>>>
>>>>>>         PR gas/24546
>>>>>>         * config/tc-i386.c (match_template): Apply AMD64/Intel64 check
>>>>>>         to 64-bit code only.
>>>>>>         * config/tc-i386.c (i386_intel_operand): Also handle CALL/JMP in
>>>>>>         O_tbyte_ptr case.
>>>>>>         * testsuite/gas/i386/x86-64-branch-3.s,
>>>>>>         testsuite/gas/i386/x86-64-intel64.s: Add 64-bit far call cases.
>>>>>>         * testsuite/gas/i386/x86-64-branch-3.d,
>>>>>>         testsuite/gas/i386/x86-64-intel64.d: Adjust expectations.
>>>>>>         * testsuite/gas/i386/x86-64-branch-5.l,
>>>>>>         testsuite/gas/i386/x86-64-branch-5.s: New.
>>>>>>         * testsuite/gas/i386/i386.exp: Run new test.
>>>>>>
>>>>>> opcodes/
>>>>>> 2020-01-XX  Jan Beulich  <jbeulich@suse.com>
>>>>>>
>>>>>>         PR gas/24546
>>>>>>         * i386-dis.c (putop): Handle REX.W in '^' case for Intel64 mode.
>>>>>>         * i386-opc.tbl (lfs, lgs, lss, lcall, ljmp): Split into
>>>>>>         AMD64 and Intel64 templates.
>>>>>>         (call, jmp): Likewise for far indirect variants. Dro
>>>>>>         Unspecified.
>>>>>>         * i386-tbl.h: Re-generate.
>>>>>
>>>>> Please add some documentations to describe how they are used in
>>>>>  AMD64 and Intel64 in AT&T/Intel syntax.
>>>>
>>>> There's nothing unusual or unexpected here. I wouldn't even know
>>>> where this would belong - are there descriptions like what you
>>>> ask for somewhere already for a fair set of other insns? I don't
>>>> recall any similar additions for any half way recent ISA
>>>> extensions, and there it might be better justified to supply
>>>> such than it is here. I guess I'm confused by the request ...
>>>
>>> We should document how new far pointer branches are used
>>> in Intel and AT&T syntax.
>>
>> I have no idea at all what you're after. Could you give me a
>> pointer to existing text I could use to clone or at least refer
>> to, which then also would give me a hint where in the docs I
>> should insert such a piece of information which - as said - I
>> don't think has a need to be there in the first place? Once
>> again
>> - usage is consistent with other insns (none of which have any
>>   such piece of documentation afaict),
>> - we shouldn't duplicate SDM / PM information.
>>
> 
> The current assembler supports far pointer branches.  Your change
> added a new one.  You should document how it differs from the
> existing one.

This

@cindex return instructions, i386
@cindex i386 jump, call, return
@cindex return instructions, x86-64
@cindex x86-64 jump, call, return
@item
Immediate form long jumps and calls are
@samp{lcall/ljmp $@var{section}, $@var{offset}} in AT&T syntax; the
Intel syntax is
@samp{call/jmp far @var{section}:@var{offset}}.  Also, the far return
instruction
is @samp{lret $@var{stack-adjust}} in AT&T syntax; Intel syntax is
@samp{ret far @var{stack-adjust}}.

and this

@cindex jump instructions, i386
@cindex call instructions, i386
@cindex jump instructions, x86-64
@cindex call instructions, x86-64
Far call/jump instructions are @samp{lcall} and @samp{ljmp} in
AT&T syntax, but are @samp{call far} and @samp{jump far} in Intel
convention.

is what I've been able to find. Neither covers - for existing
forms - what you ask for, so I'm still entirely unclear what
form of documentation of what specific aspects you're after.
Sadly you didn't address my prior request to point me at
something that I could go from. I'm afraid if you want me to
do this, you'll need to be more specific. An alternative might
be for you to put together whatever you think needs documenting.

Jan