[PATCH 2/2] x86: permit non-immediate offset operands with direct far branches

[Jan Beulich]

On 14.10.2024 08:50, H.J. Lu wrote:
> On Mon, Oct 14, 2024, 2:39 PM Jan Beulich <jbeulich@suse.com> wrote:
> 
>> While Intel syntax permits such already (as can be observed by there
>> not being a need to prefix the respective operand with "offset"), AT&T
>> syntax so far strictly insists on two immediate operands. Multiple
>> (successive) immediate operands are somewhat problematic anyway, as
>> it's never really clear what their order ought to be. While there's no
>> apparent way of dealing with this for ENTER, EXTRQ, and INSERTQ, for
>> LCALL and LJMP we can aid programmers by permitting alternative forms,
>> with the offset operand being a "displacement" rather than an
>> "immediate". The order of the two operands the doesn't matter; they're
>> distinguished by type.
>>
>> Mark the new templates AT&T-only; the original ones really should have
>> been so, too. For backwards compatibility reasons we can't really
>> correct that mistake ...
>> ---
>> While the proper Intel syntax operand form is sel:offset, for some
>> reason we also support two (comma separated) operands. The ambiguity
>> there is being left alone, as the sel:offset form is enough to avoid it.
>>
> 
> I don't think this is a good idea.  $ is used to denote an immediate
> operand in
> AT&T syntax.

Yet as with JMPABS the question is whether this really is an immediate.
Just take Lili's most recent comment there: It can be looked at as a
displacement/offset relative to the specified segment/selector. IOW like
there I think two perspectives are possible, and - as expressed by the
post-commit-message remark - they're already both supported in Intel
syntax.

>  This change serves no practical purposes for programmers.

I'm (once again) puzzled by such statements of yours: How do you know?

The main question I'd like to see answered is: Is there any (realistic)
risk of causing harm by permitting the alternative forms?

Jan