[PATCH 2/2] x86/APX: support JMPABS also in assembler

[Jan Beulich]

On 09.10.2024 08:44, H.J. Lu wrote:
> On Wed, Oct 9, 2024 at 2:36 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 09.10.2024 08:09, H.J. Lu wrote:
>>> On Wed, Oct 9, 2024 at 2:00 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 08.10.2024 23:20, H.J. Lu wrote:
>>>>> On Wed, Oct 9, 2024 at 5:00 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>> On Tue, Oct 8, 2024 at 6:26 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>> Without this APX support isn't really complete.
>>>>>>>
>>>>>>> Since which operand type to expect in source is ambiguous, permit both
>>>>>>> immediate and displacement forms. Make sure though that in Intel syntax
>>>>>>> truly memory operand forms (<xyz> ptr and/or square-bracketing) aren't
>>>>>>> accepted. Also make sure that no illegal prefixes can be used with the
>>>>>>> insn (LOCK is being dealt with more generally elsewhere).
>>>>
>>>> (Note this paragraph of the description.)
>>>>
>>>>>>> --- a/opcodes/i386-opc.tbl
>>>>>>> +++ b/opcodes/i386-opc.tbl
>>>>>>> @@ -510,6 +510,11 @@ ljmp, 0xea, No64, JumpInterSegment|No_bS
>>>>>>>  ljmp, 0xff/5, 0, Amd64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_qSuf, { Unspecified|BaseIndex }
>>>>>>>  ljmp, 0xff/5, x64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_sSuf, { Unspecified|BaseIndex }
>>>>>>>
>>>>>>> +// In particular for AT&T syntax permit both immediate and displacement form,
>>>>>>> +// to allow people to use what they see as the better fit.
>>>>>>
>>>>>> Why do we need "jmpabs $xxx" when it is encoded the same
>>>>>> as "jmpabs xxx"?  "jmpabs xxx" is sufficient.
>>>>>
>>>>> Since disassembler displays "jmpabs $xxx", only "jmpabs $xxx" is
>>>>> needed.  It is clear that jmpabs doesn't take a displacement and
>>>>> only immediate is supported.
>>>>
>>>> Already by the two replies of yours you demonstrate that both views are
>>>> possible. And you're not the first one to be confused / have mixed
>>>> feelings.
>>>>
>>>> As indicated in a post-commit-message remark I'm also intending to
>>>> relax ljmp's and lcall's requirements. I've always viewed it as a
>>>> mistake that only immediates were supported there for the offset operand.
>>>> That's simply not consistent.
>>>>
>>>> I'm further inclined to suggest that the disassembler better display the
>>>> operand without the leading $ (in AT&T mode), at least when it's not a
>>>> purely numeric one (and in particular when it has a relocation associated
>>>> with it).
>>>
>>> This is an option.  Before we go there, how does Intel syntax support
>>> "movabs r64, imm64"?
>>
>> That's no different from MOV (because of the other MOVABS form that also
>> exists):
>>
>>         MOV     rax, <symbol>
>>         MOV     rax, [<number>]
>>         MOVABS  rax, <symbol>
>>         MOVABS  rax, [<number>]
>>
>> all mean a memory operand.
>>
>>         MOV     rax, offset <symbol>
>>         MOV     rax, <number>
>>         MOVABS  rax, offset <symbol>
>>         MOVABS  rax, <number>
>>
>> all mean an immediate operand. That is
>> - a numeric value defaults to immediate, which can be overridden by
>>   enclosing the value in square brackets,
>> - a symbolic value defaults to displacement, which can be overridden by
>>   prefixing with "offset".
>>
>> As an aside - MOVABS isn't really Intel syntax and should never have been
>> supported outside of AT&T syntax.
>>
> 
> I think we should only allow the imm64 operand.  If there is a 64-bit relative
> jmp, like jmp64, in the future,  the assembly syntax will be different from
> jmpabs.

Can you explain how this would matter? The only thing to be concerned about is
(imo) whether there might be a 2nd JMPABS form down the road, taking a memory
operand. Yet that would be no different from "JMP *symbol" that's already there,
so I don't see any potential issue here. A hypothetical JMP64 can take whatever
operands it wants.

Jan