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

[H.J. Lu]

On Wed, Oct 9, 2024 at 4:48 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 09.10.2024 10:41, Hu, Lin1 wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Wednesday, October 9, 2024 4:28 PM
> >> To: Hu, Lin1 <lin1.hu@intel.com>
> >> Cc: Binutils <binutils@sourceware.org>; Cui, Lili <lili.cui@intel.com>; H.J. Lu
> >> <hjl.tools@gmail.com>
> >> Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in assembler
> >>
> >> On 09.10.2024 09:45, Hu, Lin1 wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: Wednesday, October 9, 2024 3:42 PM
> >>>>
> >>>> On 09.10.2024 09:33, H.J. Lu wrote:
> >>>>> 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).
> >>>
> >>> From doc and the results of our previous discussions with relevant colleagues,
> >> the operand should be a 64-bit immediate operand about instruction encoding.
> >> Maybe they have the same bytecode, but I don't think we should confuse them,
> >> we should make it clear to anyone who sees this instruction that it's an
> >> immediate operand.
> >>
> >> Same question as to H.J.: Why? What's wrong with it not requiring the $ in AT&T
> >> syntax and, worse, the "offset" in Intel syntax when a symbol is referenced?
> >> People wanting to use the immediate form can very well do so.
> >> People preferring the displacement form would better not be forced to use a
> >> form they're not comfortable with. Unless - as expressed before - there actually
> >> is a reason to enforce such a constraint. Yet so far I've not seen any such reason
> >> being spelled out.
> >
> > If we have another instruction like "jmpabs foo" in the future, but its opcode isn't A1, how does binutils distinguish between them?
>
> I discussed this in an earlier reply. If you have concerns there, please describe
> what that supposed insn form would do. It can't be a relative direct jump (or else
> the "abs" in the mnemonic was wrong), and if it was a relative indirect one, it'll
> require a * prefix on its operand to be consistent with other indirect branches.
> Plus, as explained earlier, that would then be exactly the same as "jmp *foo", so
> there's hardly any reason such a redundant encoding would ever be added.
>

imm64 in jmpabs is the same type as imm64 in movabs.  imm64 should be
expressed as "$symbol" in AT&T syntax.

-- 
H.J.