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

Jan Beulich jbeulich@suse.com
Wed Oct 9 08:48:47 GMT 2024


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.

Jan


More information about the Binutils mailing list