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

[Jan Beulich]

On 10.10.2024 09:51, Hu, Lin1 wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Thursday, October 10, 2024 3:05 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 10.10.2024 03:53, Hu, Lin1 wrote:
>>> I don't think linker currently supports the following forms:
>>> label:
>>> 	...
>>> 	jmpabs label
>>
>> Why would it not support this? It doesn't care at all what insn it is; all
>> it cares about is the associated relocation (R_X86_64_64 for ELF). And ...
> 
> I'm not familiar with this part. Does assembler definitely generate R_X86_64_64 rather than R_X86_64_GOTOFF64 or R_X86_64_PLTOFF64?

The assembler won't invent PLTOFF or GOTOFF when the source doesn't specify
it. If there were @pltoff or @gotoff operators (or whatever the correct forms
are) on the symbol, the assembler still has code to choke on wrong uses. I
didn't check though whether that would properly work here.

>>> 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.
>>
>> ... how does the linker come into the picture here in the first place?
> 
> We think it's safer to extend the 'jmp label' functionality in the linker without any conflict with the documentation.

That doesn't answer my question. Without that answered I'm also not understanding
your reply, I'm afraid.

Jan