Home Original page

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

Jan Beulich jbeulich@suse.com
Wed Oct 9 06:36:18 GMT 2024 
On 09.10.2024 08:09, H.J. Lu wrote:
> On Wed, Oct 9, 2024 at 2:00 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 08.10.2024 23:20, H.J. Lu wrote:
>>> On Wed, Oct 9, 2024 at 5:00 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Tue, Oct 8, 2024 at 6:26 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>> Without this APX support isn't really complete.
>>>>>
>>>>> Since which operand type to expect in source is ambiguous, permit both
>>>>> immediate and displacement forms. Make sure though that in Intel syntax
>>>>> truly memory operand forms (<xyz> ptr and/or square-bracketing) aren't
>>>>> accepted. Also make sure that no illegal prefixes can be used with the
>>>>> insn (LOCK is being dealt with more generally elsewhere).
>>
>> (Note this paragraph of the description.)
>>
>>>>> --- a/opcodes/i386-opc.tbl
>>>>> +++ b/opcodes/i386-opc.tbl
>>>>> @@ -510,6 +510,11 @@ ljmp, 0xea, No64, JumpInterSegment|No_bS
>>>>>  ljmp, 0xff/5, 0, Amd64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_qSuf, { Unspecified|BaseIndex }
>>>>>  ljmp, 0xff/5, x64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_sSuf, { Unspecified|BaseIndex }
>>>>>
>>>>> +// In particular for AT&T syntax permit both immediate and displacement form,
>>>>> +// to allow people to use what they see as the better fit.
>>>>
>>>> Why do we need "jmpabs $xxx" when it is encoded the same
>>>> as "jmpabs xxx"?  "jmpabs xxx" is sufficient.
>>>
>>> Since disassembler displays "jmpabs $xxx", only "jmpabs $xxx" is
>>> needed.  It is clear that jmpabs doesn't take a displacement and
>>> only immediate is supported.
>>
>> Already by the two replies of yours you demonstrate that both views are
>> possible. And you're not the first one to be confused / have mixed
>> feelings.
>>
>> As indicated in a post-commit-message remark I'm also intending to
>> relax ljmp's and lcall's requirements. I've always viewed it as a
>> mistake that only immediates were supported there for the offset operand.
>> That's simply not consistent.
>>
>> I'm further inclined to suggest that the disassembler better display the
>> operand without the leading $ (in AT&T mode), at least when it's not a
>> purely numeric one (and in particular when it has a relocation associated
>> with it).
> 
> This is an option.  Before we go there, how does Intel syntax support
> "movabs r64, imm64"?

That's no different from MOV (because of the other MOVABS form that also
exists):

	MOV	rax, <symbol>
	MOV	rax, [<number>]
	MOVABS	rax, <symbol>
	MOVABS	rax, [<number>]

all mean a memory operand.

	MOV	rax, offset <symbol>
	MOV	rax, <number>
	MOVABS	rax, offset <symbol>
	MOVABS	rax, <number>

all mean an immediate operand. That is
- a numeric value defaults to immediate, which can be overridden by
  enclosing the value in square brackets,
- a symbolic value defaults to displacement, which can be overridden by
  prefixing with "offset".

As an aside - MOVABS isn't really Intel syntax and should never have been
supported outside of AT&T syntax.

Jan
More information about the Binutils mailing list