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

[H.J. Lu]

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"?

-- 
H.J.