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

[Hu, Lin1]

> -----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.

BRs,
Lin