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

[Jan Beulich]

On 11.10.2024 10:57, Hu, Lin1 wrote:
>> -----Original Message-----
>> From: Hu, Lin1
>> Sent: Thursday, October 10, 2024 5:59 PM
>> To: Jan Beulich <jbeulich@suse.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
>>
>>> -----Original Message-----
>>> From: Jan Beulich <jbeulich@suse.com>
>>> Sent: Thursday, October 10, 2024 4:31 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 09:51, Hu, Lin1 wrote:
>>>>> -----Original Message-----
>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>> Sent: Thursday, October 10, 2024 3:10 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 04:41, Hu, Lin1 wrote:
>>>>>> And I think 'movabs moffs64, %rax' and 'movabs imm64, %rax' are
>>>>>> two
>>>>> different instructions, they have different opcode.
>>>>>
>>>>> Yes.
>>>>>
>>>>>> According to spec, jmpabs is closer to 'movabs imm64, %rax',
>>>>>> because jmpabs
>>>>> only accept imm64.
>>>>>
>>>>> The "because" here is unjustified, at least as long as you can't
>>>>> point me at where this is being said. Hence the "why" on the first
>>>>> part of the
>>> sentence remains open.
>>>>>
>>>>
>>>> On page 233 of Document
>>>> (https://cdrdv2.intel.com/v1/dl/getContent/784266)
>>> it is written "The 64-bit immediate operand is treated an as absolute
>>> effective address, which is subject to canonicality checks."
>>>>
>>>>>
>>>>> All the spec says is that there is a 64-bit field as the only
>>>>> operand. It says nothing on this being an immediate or a
>>>>> displacement. In fact, as
>>>>> (indirectly) pointed out before, the boundary between the two is
>>>>> actually fuzzy in the SDM; the strong distinction between them is
>>>>> something
>>> assemblers invented.
>>>>
>>>> In the document I posted above, I think it's kind of explicitly written clearly.
>>>
>>> Then please look at this text taken from the CALL insn page of the SDM:
>>>
>>> "The operand can be an immediate value, a general-purpose register, or
>>> a memory location."
>>>
>>> Since neither "general-purpose register" nor "memory location" apply
>>> to opcode E8, it must be an immediate. Yet in the assembler we call it a
>> displacement.
>>>
>>
>> In the assembler, I think we call it displacement, because its address is
>> displacement to relative to next instruction rather than the operand being an
>> immediate.
>>
>> Looking at the encoding, it may be that their operands are encoded on
>> IMMEDIATE, I don't think that means that they are generalizable in the form of
>> their use, the two operands express completely different meanings. It doesn't
>> make sense to me to use the past displacement to define the present absolute
>> address.
>>
> 
> Fix typo. "absolute address".
> 
>>>
>>>>>> If jmpabs want to accept moffs64, it should use another opcode.
>>>>>> Even if we refer to movabs, we should recognize the possibility of
>>>>>> the
>>>>> appearance of another instruction 'jmpabs moffs64'.  Abs suffix is
>>>>> not a constraint.
>>>>>>
>>>>>> And in terms of usage habits, I think people feel 0x123 is a
>>>>>> offset rather than a
>>>>> absolute address.  People unfamiliar with jmpabs might see 0x123
>>>>> and think the address is rip + 0x123 rather then just 0x123.
>>>>>
>>>>> Then they simply missed the point of the "abs" in the mnemonic.
>>>>>
>>>>
>>>> Maybe, the same thing I think has happened with movabs. I think when
>>>> people use "movabs moffs64, %rax", they ignore the "abs" in the
>>>> mnemonic, too. They determine whether it's a relative address
>>>
>>> Relative address? It's an absolute address, not a displacement
>>> relative to somewhere.
>>>
>>
>> On the top of page 1256, "The moffs8, moffs16, moffs32, and moffs64
>> operands specify a simple offset relative to the segment base, where 8, 16, 32,
>> and 64 refer to the size of the data. The address-size attribute of the instruction
>> determines the size of the offset, either 16, 32, or 64 bits."
>>
>> I think it's a displacement relative to the segment base according to the SDM.
>>
> 
> At the jump.s file, the jmp instructions encoded as EA, its format is "ljmp $0x1234,$xxx",  do you have an example like jmp is a absolute direct jump and without the '$' sign in binutils? 

As previously said, I'm going to propose a change to permit this. Not
for JMP/CALL, but for LJMP/LCALL (the proper AT&T mnemonics for these
insns). In fact I've just finished putting it together. Because of a
(seemingly unrelated) prereq change I first need to test the pair in
a wider fashion, before I can submit them.

Jan