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

[Cui, Lili]

> 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
+	jmpabs	0x87654321
+	jmpabs	0x987654321


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


Lili.