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

[Jan Beulich]

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

there's also nothing RIP-relative. That's what (aiui) the "abs" part of the
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

Jan

> +	jmpabs	0x87654321
> +	jmpabs	0x987654321
> 
> 
> +	jmpabs	$0x12345678  ---> tempRIP = 0x12345678
> +	jmpabs	$0x87654321
> +	jmpabs	$0x987654321
> 
> 
> Lili.