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

[H.J. Lu]

On Wed, Oct 9, 2024 at 3:42 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 09.10.2024 09:33, H.J. Lu wrote:
> > On Wed, Oct 9, 2024 at 3:29 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> 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.
> >
> > It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be "jmp64 foo"
> > if there is one.
>
> As to the latter - of course. But how does the latter constrain the former in any
> way? I'm sorry to say that, but you make statements without actually providing
> explanations. Yet it's the explanation that's crucial here if you want to
> convince me of (or at least make me understand) your view of the situation. I for
> one did explain why I think we'd better support both forms (and you demonstrated
> that I'm right there by the two contradicting initial replies of yours).
>
> Jan

In AT&T syntax, foo is an address operand and $foo is an immediate
operand.  Since jmpabs takes an immediate operand, only $foo is valid.

-- 
H.J.