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

[Hu, Lin1]

> -----Original Message-----
> From: Hu, Lin1
> Sent: Thursday, October 10, 2024 9:54 AM
> To: 'Jan Beulich' <jbeulich@suse.com>; H.J. Lu <hjl.tools@gmail.com>
> Cc: Binutils <binutils@sourceware.org>; Cui, Lili <lili.cui@intel.com>
> Subject: RE: [PATCH 2/2] x86/APX: support JMPABS also in assembler
> 
> > -----Original Message-----
> > From: Jan Beulich <jbeulich@suse.com>
> > Sent: Wednesday, October 9, 2024 7:40 PM
> > To: H.J. Lu <hjl.tools@gmail.com>
> > Cc: Hu, Lin1 <lin1.hu@intel.com>; Binutils <binutils@sourceware.org>;
> > Cui, Lili <lili.cui@intel.com>
> > Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in assembler
> >
> > On 09.10.2024 12:51, H.J. Lu wrote:
> > > On Wed, Oct 9, 2024, 6:16 PM Jan Beulich <jbeulich@suse.com> wrote:
> > >
> > >> On 09.10.2024 11:52, H.J. Lu wrote:
> > >>> 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.
> > >>
> > >> Which of the two MOVABS forms do you mean? The A0/A1 encoding
> > >
> > > The one with the imm64 entry.
> >
> > Come on, don't have me ask for every detail. Why would it be that one
> > to compare with and not ...
> >
> > > doesn't use
> > >> imm64 but moffs, and clearly that's closer to JMPABS (same opcode,
> > >> different just by REX/REX2)
> >
> > ... this other one?
> >
> > Just to repeat - it doesn't help move the discussion forward if you
> > merely make statements, without backing them up with respective
> > reasoning. I can't help getting the impression that you simply can't
> > justify what you want, and it's instead merely a subjective choice of yours.
> >
> > >> than the B8...BF encodings.
> >
> 
> I don't think linker currently supports the following forms:
> label:
> 	...
> 	jmpabs label
> 
> Same thing we discussed earlier, it's pointless to support this format now. And
> for the form that uses label, maybe we can consider let linker to convert 'jmp
> label''s encoding to jmpabs's. For gas, even if the likelihood of a new instruction
> like 'jmpabs 0x521515' appearing is small, that's no reason for us to accept this
> usage; we think it's safer to let the linker support it.
> 

And I think 'movabs moffs64, %rax' and 'movabs imm64, %rax' are two different instructions, they have different opcode.
According to spec, jmpabs is closer to 'movabs imm64, %rax', because jmpabs only accept imm64. If jmpabs want to accept moffs64, it should use another opcode.
Even if we refer to movabs, we should recognize the possibility of the appearance of another instruction 'jmpabs moffs64'.  Abs suffix is not a constraint.

And in terms of usage habits, I think people feel 0x123 is a offset rather than a absolute address.  People unfamiliar with jmpabs might see 0x123 and think the address is rip + 0x123 rather then just 0x123.

BRs,
Lin