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

[Jan Beulich]

On 14.10.2024 05:54, Cui, Lili wrote:
> 
> 
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, October 11, 2024 5:03 PM
>> To: Cui, Lili <lili.cui@intel.com>
>> Cc: Hu, Lin1 <lin1.hu@intel.com>; Binutils <binutils@sourceware.org>; H.J. Lu
>> <hjl.tools@gmail.com>
>> Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in assembler
>>
>> On 11.10.2024 08:43, Cui, Lili wrote:
>>>> On 11.10.2024 04:51, Cui, Lili wrote:
>>>>>> On 10.10.2024 10:57, Cui, Lili wrote:
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>>>> Sent: Thursday, October 10, 2024 3:24 PM
>>>>>>>>
>>>>>>>> On 10.10.2024 04:54, Cui, Lili wrote:
>>>>>>>>> 'jmpabs $foo' and 'jmpabs foo' are really two different things,
>>>>>>>>> if used as an
>>>>>>>> offset, its access range is different from that of an immediate value.
>>>>>>>>
>>>>>>>> Can you clarify what you mean here, please? What's "access range"?
>>>>>>>>
>>>>>>>
>>>>>>> Forget it, I thought wrong before.
>>>>>>>
>>>>>>>>> supporting both formats will confuse users.
>>>>>>>>
>>>>>>>> That's your view. Mine is that already the prior discussion here
>>>>>>>> has proven that it'll actually help users, by allowing them
>>>>>>>> freedom in how to write their code.
>>>>>>>>
>>>>>>>>> Is this an immediate value or an offset? But in fact, this is an
>>>>>>>>> immediate
>>>>>>>> value.
>>>>>>>>
>>>>>>>> No more or less than the immediates in e.g. opcodes E8 and E9. As
>>>>>>>> said in a reply to Lin, the distinction between "immediate" and
>>>>>> "displacement"
>>>>>>>> is blurred anyway in the SDM.
>>>>>>>
>>>>>>> I checked the documentation for E8 and E9, and they are both
>>>>>>> offsets, so there
>>>>>> is no ambiguity.
>>>>>>>
>>>>>>> E8: Call near, relative, displacement relative to next instruction.
>>>>>>> E9: Jump near, relative, displacement relative to next instruction.
>>>>>>> Not
>>>>>> supported in 64-bit mode.
>>>>> E9 : JMP rel32
>>>>>>
>>>>>> Quoting the same piece from the CALL page of the SDM for you then:
>>>>>> "The operand can be an immediate value, a general-purpose register,
>>>>>> or a memory location." Note the word "immediate" and how it's not
>>>>>> an immediate in the assembler.
>>>>>>
>>>>>
>>>>> Those who are familiar with this instruction should know that it is
>>>>> an offset. If
>>>> some information descriptions are unclear or inaccurate, please read
>>>> it together with all the relevant information.
>>>>
>>>> Thing is (and I said this before) - what the manual says, which is
>>>> focused on insn encoding - isn't always tightly connected to how
>>>> something wants / needs expressing in assembly source. What is being
>>>> said there can be taken as guideline, but needs to further be taken with a
>> grain of salt.
>>>>
>>>>> Even if the description here is unclear, we should not mix immediate
>>>>> and offset
>>>> together, which will make things more and more confusing and cause
>>>> trouble for those who have a clear concept. For those who are clear,
>>>> the first reaction is that the linker will recalculate and backfill
>>>> the absolute address based on the current offset, but that's not your
>> intention.
>>>>
>>>> I'm afraid I can't put the pieces here together to give a consistent picture.
>>>> Yes, the linker _will_ recalculate and fill absolute addresses.
>>>> That's true for all of
>>>>
>>>> 	movabs	$symbol, %rax
>>>> 	movabs	symbol, %rax
>>>> 	jmpabs	$symbol, %rax
>>>> 	jmpabs	symbol, %rax
>>>>
>>>
>>> I mean the following test cases you created in your patch.
>>>
>>> +	jmpabs	0x12345678   ---> tempRIP = RIP + 0x12345678
>>
>> What would this RIP-relativeness follow from? In
>>
>> 	mov	0x12345678, %eax
>> 	movabs	0x12345678, %eax
>>
> 
> 0x12345678 is also an offset, relative to the segment base, SDM marks it as moffs, which means " Move doubleword at (seg:offset) to EAX" (the real address is segment base + 0x12345678). 
> 
> We also have immediate one.
>         
>               mov	$0x12345678, %eax
>               movabs	$0x12345678, %eax
> 
> 
>> there's also nothing RIP-relative. That's what (aiui) the "abs" part of the
> 
> It is an offset relative to the segment base, emphasizing that it is an offset, not immediate.

Yet you didn't address my remark regarding you saying "tempRIP = RIP + 0x12345678"
in your earlier reply.

>> mnemonic is about, as extra disambiguation. As you can see from the two
>> examples, that wouldn't even be strictly required if looking at just how operands
>> are spelled. Instead something was (kind of) needed in order to properly
>> separate the new insn from
>>
>> 	jmp	0x12345678
>>
> 
> jmp	0x12345678
> JMP : Jump near, relative, RIP = RIP + 32-bit displacement sign extended to 64-bits.  
> 
> jmpabs $0x12345678
> JMPABS: The 64-bit immediate operand is treated an as absolute effective address, which is subject to canonicality
> checks.
> 
> These two formats just reflect the difference between offset and immediate.
> Why add jmpabs 0x12345678 to confuse the concept?

This question was already answered - Because people may look at this differently.
Besides confusion that I saw elsewhere, I can only direct you back to H.J.'s
initial replies, which demonstrated the two way of looking at this pretty well.

And there's nothing "to confuse" here: Following your argumentation further up,
the operand is relative to the CS segment base. That's always zero in 64-bit
mode, but conceptually still exists. The operand also is an address, not a
"plain number".

Jan