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

  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).
---
Instead of open-coding the check for JMPABS in establish_rex() we could
of course also introduce a new "no sizing prefixes" operand constraint.

Because of the similarity with the offset part of directl long/far
branches, I'm actually inclined to introduce Disp<NN> variants there,
too. That, when used in source code, would then also make more clear
which one is which.
  

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).
> ---
> Instead of open-coding the check for JMPABS in establish_rex() we could
> of course also introduce a new "no sizing prefixes" operand constraint.
>
> Because of the similarity with the offset part of directl long/far
> branches, I'm actually inclined to introduce Disp<NN> variants there,
> too. That, when used in source code, would then also make more clear
> which one is which.
>
> --- a/gas/config/tc-i386.c
> +++ b/gas/config/tc-i386.c
> @@ -4673,6 +4673,24 @@ static void establish_rex (void)
>
>    if (is_apx_rex2_encoding ())
>      {
> +      /* Most prefixes are not permitted with JMPABS.  */
> +      if (i.tm.mnem_off == MN_jmpabs)
> +       {
> +         if (i.prefix[DATA_PREFIX] || (i.prefix[REX_PREFIX] & REX_W))
> +           {
> +             as_bad (_("size override not allowed with `%s'"),
> +                     insn_name (&i.tm));
> +             i.prefix[DATA_PREFIX] = 0;
> +             i.prefix[REX_PREFIX] &= ~REX_W;
> +           }
> +         if (i.prefix[ADDR_PREFIX])
> +           {
> +             as_bad (_("address override not allowed with `%s'"),
> +                     insn_name (&i.tm));
> +             i.prefix[ADDR_PREFIX] = 0;
> +           }
> +       }
> +
>        build_rex2_prefix ();
>        /* The individual REX.RXBW bits got consumed.  */
>        i.rex &= REX_OPCODE;
> @@ -8214,7 +8232,8 @@ optimize_imm (void)
>                /* A more generic (but also more involved) way of dealing
>                   with the special case(s) would be to go look for
>                   DefaultSize attributes on any of the templates.  */
> -              && current_templates.start->mnem_off != MN_push))
> +              && current_templates.start->mnem_off != MN_push
> +              && current_templates.start->mnem_off != MN_jmpabs))
>      guess_suffix = LONG_MNEM_SUFFIX;
>
>    for (op = i.operands; --op >= 0;)
> @@ -8360,10 +8379,10 @@ optimize_disp (const insn_template *t)
>         }
>      }
>
> -  /* Don't optimize displacement for movabs since it only takes 64bit
> -     displacement.  */
> +  /* Don't optimize displacement for movabs / jmpabs since they only take
> +     64-bit displacement.  */
>    if (pp.disp_encoding > disp_encoding_8bit
> -      || (flag_code == CODE_64BIT && t->mnem_off == MN_movabs))
> +      || t->mnem_off == MN_movabs || t->mnem_off == MN_jmpabs)
>      return true;
>
>    for (op = i.operands; op-- > 0;)
> --- a/gas/config/tc-i386-intel.c
> +++ b/gas/config/tc-i386-intel.c
> @@ -907,7 +907,8 @@ i386_intel_operand (char *operand_string
>    /* Operands for jump/call need special consideration.  */
>    if (current_templates.start->opcode_modifier.jump == JUMP
>        || current_templates.start->opcode_modifier.jump == JUMP_DWORD
> -      || current_templates.start->opcode_modifier.jump == JUMP_INTERSEGMENT)
> +      || current_templates.start->opcode_modifier.jump == JUMP_INTERSEGMENT
> +      || current_templates.start->mnem_off == MN_jmpabs)
>      {
>        bool jumpabsolute = false;
>
> --- a/gas/testsuite/gas/i386/x86-64-apx-jmpabs.d
> +++ b/gas/testsuite/gas/i386/x86-64-apx-jmpabs.d
> @@ -1,5 +1,5 @@
>  #as:
> -#objdump: -dw
> +#objdump: -dwr
>  #name: x86_64 APX_F JMPABS insns
>  #source: x86-64-apx-jmpabs.s
>
> @@ -8,5 +8,16 @@
>  Disassembly of section \.text:
>
>  0+ <_start>:
> +\s*[a-f0-9]+:\s*d5 00 a1 00 00 00 00 00 00 00 00[       ]+jmpabs \$0x0\s*[a-f0-9]+: (R_X86_64_|IMAGE_REL_AMD64_ADDR)?64        thunk
>  \s*[a-f0-9]+:\s*d5 00 a1 02 00 00 00 00 00 00 00[       ]+jmpabs \$0x2
> +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 00 00 00 00[       ]+jmpabs \$0x87654321
> +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 09 00 00 00[       ]+jmpabs \$0x987654321
> +\s*[a-f0-9]+:\s*d5 00 a1 00 00 00 00 00 00 00 00[       ]+jmpabs \$0x0\s*[a-f0-9]+: (R_X86_64_|IMAGE_REL_AMD64_ADDR)?64        thunk
> +\s*[a-f0-9]+:\s*d5 00 a1 78 56 34 12 00 00 00 00[       ]+jmpabs \$0x12345678
> +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 00 00 00 00[       ]+jmpabs \$0x87654321
> +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 09 00 00 00[       ]+jmpabs \$0x987654321
> +\s*[a-f0-9]+:\s*d5 00 a1 00 00 00 00 00 00 00 00[       ]+jmpabs \$0x0\s*[a-f0-9]+: (R_X86_64_|IMAGE_REL_AMD64_ADDR)?64        thunk
> +\s*[a-f0-9]+:\s*d5 00 a1 78 56 34 12 00 00 00 00[       ]+jmpabs \$0x12345678
> +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 00 00 00 00[       ]+jmpabs \$0x87654321
> +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 09 00 00 00[       ]+jmpabs \$0x987654321
>  #pass
> --- a/gas/testsuite/gas/i386/x86-64-apx-jmpabs.s
> +++ b/gas/testsuite/gas/i386/x86-64-apx-jmpabs.s
> @@ -2,4 +2,18 @@
>
>         .text
>   _start:
> -       .byte 0xd5,0x00,0xa1,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> +       jmpabs  thunk
> +       jmpabs  2
> +       jmpabs  0x87654321
> +       jmpabs  0x987654321
> +
> +       jmpabs  $thunk
> +       jmpabs  $0x12345678
> +       jmpabs  $0x87654321
> +       jmpabs  $0x987654321
> +
> +       .intel_syntax noprefix
> +       jmpabs  thunk
> +       jmpabs  0x12345678
> +       jmpabs  0x87654321
> +       jmpabs  0x987654321
> --- a/gas/testsuite/gas/i386/x86-64-apx-jmpabs-intel.d
> +++ b/gas/testsuite/gas/i386/x86-64-apx-jmpabs-intel.d
> @@ -1,5 +1,5 @@
>  #as:
> -#objdump: -dw -Mintel
> +#objdump: -dwr -Mintel
>  #name: x86_64 APX_F JMPABS insns (Intel disassembly)
>  #source: x86-64-apx-jmpabs.s
>
> @@ -8,5 +8,16 @@
>  Disassembly of section \.text:
>
>  0+ <_start>:
> +\s*[a-f0-9]+:\s*d5 00 a1 00 00 00 00 00 00 00 00[       ]+jmpabs 0x0\s*[a-f0-9]+: (R_X86_64_|IMAGE_REL_AMD64_ADDR)?64  thunk
>  \s*[a-f0-9]+:\s*d5 00 a1 02 00 00 00 00 00 00 00[       ]+jmpabs 0x2
> +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 00 00 00 00[       ]+jmpabs 0x87654321
> +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 09 00 00 00[       ]+jmpabs 0x987654321
> +\s*[a-f0-9]+:\s*d5 00 a1 00 00 00 00 00 00 00 00[       ]+jmpabs 0x0\s*[a-f0-9]+: (R_X86_64_|IMAGE_REL_AMD64_ADDR)?64  thunk
> +\s*[a-f0-9]+:\s*d5 00 a1 78 56 34 12 00 00 00 00[       ]+jmpabs 0x12345678
> +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 00 00 00 00[       ]+jmpabs 0x87654321
> +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 09 00 00 00[       ]+jmpabs 0x987654321
> +\s*[a-f0-9]+:\s*d5 00 a1 00 00 00 00 00 00 00 00[       ]+jmpabs 0x0\s*[a-f0-9]+: (R_X86_64_|IMAGE_REL_AMD64_ADDR)?64  thunk
> +\s*[a-f0-9]+:\s*d5 00 a1 78 56 34 12 00 00 00 00[       ]+jmpabs 0x12345678
> +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 00 00 00 00[       ]+jmpabs 0x87654321
> +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 09 00 00 00[       ]+jmpabs 0x987654321
>  #pass
> --- 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.

> +jmpabs, 0xa1, APX_F, NoSuf|Rex2, { Imm64 }
> +jmpabs, 0xa1, APX_F, NoSuf|Rex2, { Disp64|Unspecified }
> +
>  ret, 0xc3, No64, ImplicitStackOp|DefaultSize|No_bSuf|No_sSuf|No_qSuf|RepPrefixOk|BNDPrefixOk|IntelSuffix, {}
>  ret, 0xc2, No64, ImplicitStackOp|DefaultSize|No_bSuf|No_sSuf|No_qSuf|RepPrefixOk|BNDPrefixOk|IntelSuffix, { Imm16 }
>  ret, 0xc3, x64, Amd64|ImplicitStackOp|DefaultSize|No_bSuf|No_lSuf|No_sSuf|NoRex64|RepPrefixOk|BNDPrefixOk|IntelSuffix, {}
>
  

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).
> > ---
> > Instead of open-coding the check for JMPABS in establish_rex() we could
> > of course also introduce a new "no sizing prefixes" operand constraint.
> >
> > Because of the similarity with the offset part of directl long/far
> > branches, I'm actually inclined to introduce Disp<NN> variants there,
> > too. That, when used in source code, would then also make more clear
> > which one is which.
> >
> > --- a/gas/config/tc-i386.c
> > +++ b/gas/config/tc-i386.c
> > @@ -4673,6 +4673,24 @@ static void establish_rex (void)
> >
> >    if (is_apx_rex2_encoding ())
> >      {
> > +      /* Most prefixes are not permitted with JMPABS.  */
> > +      if (i.tm.mnem_off == MN_jmpabs)
> > +       {
> > +         if (i.prefix[DATA_PREFIX] || (i.prefix[REX_PREFIX] & REX_W))
> > +           {
> > +             as_bad (_("size override not allowed with `%s'"),
> > +                     insn_name (&i.tm));
> > +             i.prefix[DATA_PREFIX] = 0;
> > +             i.prefix[REX_PREFIX] &= ~REX_W;
> > +           }
> > +         if (i.prefix[ADDR_PREFIX])
> > +           {
> > +             as_bad (_("address override not allowed with `%s'"),
> > +                     insn_name (&i.tm));
> > +             i.prefix[ADDR_PREFIX] = 0;
> > +           }
> > +       }
> > +
> >        build_rex2_prefix ();
> >        /* The individual REX.RXBW bits got consumed.  */
> >        i.rex &= REX_OPCODE;
> > @@ -8214,7 +8232,8 @@ optimize_imm (void)
> >                /* A more generic (but also more involved) way of dealing
> >                   with the special case(s) would be to go look for
> >                   DefaultSize attributes on any of the templates.  */
> > -              && current_templates.start->mnem_off != MN_push))
> > +              && current_templates.start->mnem_off != MN_push
> > +              && current_templates.start->mnem_off != MN_jmpabs))
> >      guess_suffix = LONG_MNEM_SUFFIX;
> >
> >    for (op = i.operands; --op >= 0;)
> > @@ -8360,10 +8379,10 @@ optimize_disp (const insn_template *t)
> >         }
> >      }
> >
> > -  /* Don't optimize displacement for movabs since it only takes 64bit
> > -     displacement.  */
> > +  /* Don't optimize displacement for movabs / jmpabs since they only take
> > +     64-bit displacement.  */
> >    if (pp.disp_encoding > disp_encoding_8bit
> > -      || (flag_code == CODE_64BIT && t->mnem_off == MN_movabs))
> > +      || t->mnem_off == MN_movabs || t->mnem_off == MN_jmpabs)
> >      return true;
> >
> >    for (op = i.operands; op-- > 0;)
> > --- a/gas/config/tc-i386-intel.c
> > +++ b/gas/config/tc-i386-intel.c
> > @@ -907,7 +907,8 @@ i386_intel_operand (char *operand_string
> >    /* Operands for jump/call need special consideration.  */
> >    if (current_templates.start->opcode_modifier.jump == JUMP
> >        || current_templates.start->opcode_modifier.jump == JUMP_DWORD
> > -      || current_templates.start->opcode_modifier.jump == JUMP_INTERSEGMENT)
> > +      || current_templates.start->opcode_modifier.jump == JUMP_INTERSEGMENT
> > +      || current_templates.start->mnem_off == MN_jmpabs)
> >      {
> >        bool jumpabsolute = false;
> >
> > --- a/gas/testsuite/gas/i386/x86-64-apx-jmpabs.d
> > +++ b/gas/testsuite/gas/i386/x86-64-apx-jmpabs.d
> > @@ -1,5 +1,5 @@
> >  #as:
> > -#objdump: -dw
> > +#objdump: -dwr
> >  #name: x86_64 APX_F JMPABS insns
> >  #source: x86-64-apx-jmpabs.s
> >
> > @@ -8,5 +8,16 @@
> >  Disassembly of section \.text:
> >
> >  0+ <_start>:
> > +\s*[a-f0-9]+:\s*d5 00 a1 00 00 00 00 00 00 00 00[       ]+jmpabs \$0x0\s*[a-f0-9]+: (R_X86_64_|IMAGE_REL_AMD64_ADDR)?64        thunk
> >  \s*[a-f0-9]+:\s*d5 00 a1 02 00 00 00 00 00 00 00[       ]+jmpabs \$0x2
> > +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 00 00 00 00[       ]+jmpabs \$0x87654321
> > +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 09 00 00 00[       ]+jmpabs \$0x987654321
> > +\s*[a-f0-9]+:\s*d5 00 a1 00 00 00 00 00 00 00 00[       ]+jmpabs \$0x0\s*[a-f0-9]+: (R_X86_64_|IMAGE_REL_AMD64_ADDR)?64        thunk
> > +\s*[a-f0-9]+:\s*d5 00 a1 78 56 34 12 00 00 00 00[       ]+jmpabs \$0x12345678
> > +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 00 00 00 00[       ]+jmpabs \$0x87654321
> > +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 09 00 00 00[       ]+jmpabs \$0x987654321
> > +\s*[a-f0-9]+:\s*d5 00 a1 00 00 00 00 00 00 00 00[       ]+jmpabs \$0x0\s*[a-f0-9]+: (R_X86_64_|IMAGE_REL_AMD64_ADDR)?64        thunk
> > +\s*[a-f0-9]+:\s*d5 00 a1 78 56 34 12 00 00 00 00[       ]+jmpabs \$0x12345678
> > +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 00 00 00 00[       ]+jmpabs \$0x87654321
> > +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 09 00 00 00[       ]+jmpabs \$0x987654321
> >  #pass
> > --- a/gas/testsuite/gas/i386/x86-64-apx-jmpabs.s
> > +++ b/gas/testsuite/gas/i386/x86-64-apx-jmpabs.s
> > @@ -2,4 +2,18 @@
> >
> >         .text
> >   _start:
> > -       .byte 0xd5,0x00,0xa1,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> > +       jmpabs  thunk
> > +       jmpabs  2
> > +       jmpabs  0x87654321
> > +       jmpabs  0x987654321
> > +
> > +       jmpabs  $thunk
> > +       jmpabs  $0x12345678
> > +       jmpabs  $0x87654321
> > +       jmpabs  $0x987654321
> > +
> > +       .intel_syntax noprefix
> > +       jmpabs  thunk
> > +       jmpabs  0x12345678
> > +       jmpabs  0x87654321
> > +       jmpabs  0x987654321
> > --- a/gas/testsuite/gas/i386/x86-64-apx-jmpabs-intel.d
> > +++ b/gas/testsuite/gas/i386/x86-64-apx-jmpabs-intel.d
> > @@ -1,5 +1,5 @@
> >  #as:
> > -#objdump: -dw -Mintel
> > +#objdump: -dwr -Mintel
> >  #name: x86_64 APX_F JMPABS insns (Intel disassembly)
> >  #source: x86-64-apx-jmpabs.s
> >
> > @@ -8,5 +8,16 @@
> >  Disassembly of section \.text:
> >
> >  0+ <_start>:
> > +\s*[a-f0-9]+:\s*d5 00 a1 00 00 00 00 00 00 00 00[       ]+jmpabs 0x0\s*[a-f0-9]+: (R_X86_64_|IMAGE_REL_AMD64_ADDR)?64  thunk
> >  \s*[a-f0-9]+:\s*d5 00 a1 02 00 00 00 00 00 00 00[       ]+jmpabs 0x2
> > +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 00 00 00 00[       ]+jmpabs 0x87654321
> > +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 09 00 00 00[       ]+jmpabs 0x987654321
> > +\s*[a-f0-9]+:\s*d5 00 a1 00 00 00 00 00 00 00 00[       ]+jmpabs 0x0\s*[a-f0-9]+: (R_X86_64_|IMAGE_REL_AMD64_ADDR)?64  thunk
> > +\s*[a-f0-9]+:\s*d5 00 a1 78 56 34 12 00 00 00 00[       ]+jmpabs 0x12345678
> > +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 00 00 00 00[       ]+jmpabs 0x87654321
> > +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 09 00 00 00[       ]+jmpabs 0x987654321
> > +\s*[a-f0-9]+:\s*d5 00 a1 00 00 00 00 00 00 00 00[       ]+jmpabs 0x0\s*[a-f0-9]+: (R_X86_64_|IMAGE_REL_AMD64_ADDR)?64  thunk
> > +\s*[a-f0-9]+:\s*d5 00 a1 78 56 34 12 00 00 00 00[       ]+jmpabs 0x12345678
> > +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 00 00 00 00[       ]+jmpabs 0x87654321
> > +\s*[a-f0-9]+:\s*d5 00 a1 21 43 65 87 09 00 00 00[       ]+jmpabs 0x987654321
> >  #pass
> > --- 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.

> > +jmpabs, 0xa1, APX_F, NoSuf|Rex2, { Imm64 }
> > +jmpabs, 0xa1, APX_F, NoSuf|Rex2, { Disp64|Unspecified }
> > +
> >  ret, 0xc3, No64, ImplicitStackOp|DefaultSize|No_bSuf|No_sSuf|No_qSuf|RepPrefixOk|BNDPrefixOk|IntelSuffix, {}
> >  ret, 0xc2, No64, ImplicitStackOp|DefaultSize|No_bSuf|No_sSuf|No_qSuf|RepPrefixOk|BNDPrefixOk|IntelSuffix, { Imm16 }
> >  ret, 0xc3, x64, Amd64|ImplicitStackOp|DefaultSize|No_bSuf|No_lSuf|No_sSuf|NoRex64|RepPrefixOk|BNDPrefixOk|IntelSuffix, {}
> >
>
>
> --
> H.J.
  

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).

Jan
  

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

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
  

On Wed, Oct 9, 2024 at 2:36 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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.
>

I think we should only allow the imm64 operand.  If there is a 64-bit relative
jmp, like jmp64, in the future,  the assembly syntax will be different from
jmpabs.
  

On 09.10.2024 08:44, H.J. Lu wrote:
> On Wed, Oct 9, 2024 at 2:36 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> 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.
>>
> 
> I think we should only allow the imm64 operand.  If there is a 64-bit relative
> jmp, like jmp64, in the future,  the assembly syntax will be different from
> jmpabs.

Can you explain how this would matter? The only thing to be concerned about is
(imo) whether there might be a 2nd JMPABS form down the road, taking a memory
operand. Yet that would be no different from "JMP *symbol" that's already there,
so I don't see any potential issue here. A hypothetical JMP64 can take whatever
operands it wants.

Jan
  

On Wed, Oct 9, 2024 at 3:29 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 09.10.2024 08:44, H.J. Lu wrote:
> > On Wed, Oct 9, 2024 at 2:36 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> 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.
> >>
> >
> > I think we should only allow the imm64 operand.  If there is a 64-bit relative
> > jmp, like jmp64, in the future,  the assembly syntax will be different from
> > jmpabs.
>
> Can you explain how this would matter? The only thing to be concerned about is
> (imo) whether there might be a 2nd JMPABS form down the road, taking a memory
> operand. Yet that would be no different from "JMP *symbol" that's already there,
> so I don't see any potential issue here. A hypothetical JMP64 can take whatever
> operands it wants.
>
> Jan

It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be "jmp64 foo"
if there is one.
  

On 09.10.2024 09:33, H.J. Lu wrote:
> On Wed, Oct 9, 2024 at 3:29 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 09.10.2024 08:44, H.J. Lu wrote:
>>> On Wed, Oct 9, 2024 at 2:36 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> 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.
>>>>
>>>
>>> I think we should only allow the imm64 operand.  If there is a 64-bit relative
>>> jmp, like jmp64, in the future,  the assembly syntax will be different from
>>> jmpabs.
>>
>> Can you explain how this would matter? The only thing to be concerned about is
>> (imo) whether there might be a 2nd JMPABS form down the road, taking a memory
>> operand. Yet that would be no different from "JMP *symbol" that's already there,
>> so I don't see any potential issue here. A hypothetical JMP64 can take whatever
>> operands it wants.
> 
> It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be "jmp64 foo"
> if there is one.

As to the latter - of course. But how does the latter constrain the former in any
way? I'm sorry to say that, but you make statements without actually providing
explanations. Yet it's the explanation that's crucial here if you want to
convince me of (or at least make me understand) your view of the situation. I for
one did explain why I think we'd better support both forms (and you demonstrated
that I'm right there by the two contradicting initial replies of yours).

Jan
  

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, October 9, 2024 3:42 PM
> To: H.J. Lu <hjl.tools@gmail.com>
> Cc: Binutils <binutils@sourceware.org>; Cui, Lili <lili.cui@intel.com>
> Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in assembler
> 
> On 09.10.2024 09:33, H.J. Lu wrote:
> > On Wed, Oct 9, 2024 at 3:29 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 09.10.2024 08:44, H.J. Lu wrote:
> >>> On Wed, Oct 9, 2024 at 2:36 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> 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.
> >>>>
> >>>
> >>> I think we should only allow the imm64 operand.  If there is a 64-bit relative
> >>> jmp, like jmp64, in the future,  the assembly syntax will be different from
> >>> jmpabs.
> >>
> >> Can you explain how this would matter? The only thing to be concerned
> about is
> >> (imo) whether there might be a 2nd JMPABS form down the road, taking a
> memory
> >> operand. Yet that would be no different from "JMP *symbol" that's already
> there,
> >> so I don't see any potential issue here. A hypothetical JMP64 can take
> whatever
> >> operands it wants.
> >
> > It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be "jmp64 foo"
> > if there is one.
> 
> As to the latter - of course. But how does the latter constrain the former in any
> way? I'm sorry to say that, but you make statements without actually providing
> explanations. Yet it's the explanation that's crucial here if you want to
> convince me of (or at least make me understand) your view of the situation. I for
> one did explain why I think we'd better support both forms (and you
> demonstrated
> that I'm right there by the two contradicting initial replies of yours).
> 
> Jan

From doc and the results of our previous discussions with relevant colleagues, the operand should be a 64-bit immediate operand about instruction encoding.  Maybe they have the same bytecode, but I don't think we should confuse them, we should make it clear to anyone who sees this instruction that it's an immediate operand.

BRs
Lin
  

On Wed, Oct 9, 2024 at 3:42 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 09.10.2024 09:33, H.J. Lu wrote:
> > On Wed, Oct 9, 2024 at 3:29 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 09.10.2024 08:44, H.J. Lu wrote:
> >>> On Wed, Oct 9, 2024 at 2:36 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> 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.
> >>>>
> >>>
> >>> I think we should only allow the imm64 operand.  If there is a 64-bit relative
> >>> jmp, like jmp64, in the future,  the assembly syntax will be different from
> >>> jmpabs.
> >>
> >> Can you explain how this would matter? The only thing to be concerned about is
> >> (imo) whether there might be a 2nd JMPABS form down the road, taking a memory
> >> operand. Yet that would be no different from "JMP *symbol" that's already there,
> >> so I don't see any potential issue here. A hypothetical JMP64 can take whatever
> >> operands it wants.
> >
> > It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be "jmp64 foo"
> > if there is one.
>
> As to the latter - of course. But how does the latter constrain the former in any
> way? I'm sorry to say that, but you make statements without actually providing
> explanations. Yet it's the explanation that's crucial here if you want to
> convince me of (or at least make me understand) your view of the situation. I for
> one did explain why I think we'd better support both forms (and you demonstrated
> that I'm right there by the two contradicting initial replies of yours).
>
> Jan

In AT&T syntax, foo is an address operand and $foo is an immediate
operand.  Since jmpabs takes an immediate operand, only $foo is valid.
  

On 09.10.2024 09:45, Hu, Lin1 wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Wednesday, October 9, 2024 3:42 PM
>>
>> On 09.10.2024 09:33, H.J. Lu wrote:
>>> It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be "jmp64 foo"
>>> if there is one.
>>
>> As to the latter - of course. But how does the latter constrain the former in any
>> way? I'm sorry to say that, but you make statements without actually providing
>> explanations. Yet it's the explanation that's crucial here if you want to
>> convince me of (or at least make me understand) your view of the situation. I for
>> one did explain why I think we'd better support both forms (and you
>> demonstrated
>> that I'm right there by the two contradicting initial replies of yours).
> 
> From doc and the results of our previous discussions with relevant colleagues, the operand should be a 64-bit immediate operand about instruction encoding.  Maybe they have the same bytecode, but I don't think we should confuse them, we should make it clear to anyone who sees this instruction that it's an immediate operand.

Same question as to H.J.: Why? What's wrong with it not requiring the $
in AT&T syntax and, worse, the "offset" in Intel syntax when a symbol is
referenced? People wanting to use the immediate form can very well do so.
People preferring the displacement form would better not be forced to use
a form they're not comfortable with. Unless - as expressed before - there
actually is a reason to enforce such a constraint. Yet so far I've not
seen any such reason being spelled out.

Jan
  

On 09.10.2024 09:45, H.J. Lu wrote:
> On Wed, Oct 9, 2024 at 3:42 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 09.10.2024 09:33, H.J. Lu wrote:
>>> On Wed, Oct 9, 2024 at 3:29 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 09.10.2024 08:44, H.J. Lu wrote:
>>>>> On Wed, Oct 9, 2024 at 2:36 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> I think we should only allow the imm64 operand.  If there is a 64-bit relative
>>>>> jmp, like jmp64, in the future,  the assembly syntax will be different from
>>>>> jmpabs.
>>>>
>>>> Can you explain how this would matter? The only thing to be concerned about is
>>>> (imo) whether there might be a 2nd JMPABS form down the road, taking a memory
>>>> operand. Yet that would be no different from "JMP *symbol" that's already there,
>>>> so I don't see any potential issue here. A hypothetical JMP64 can take whatever
>>>> operands it wants.
>>>
>>> It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be "jmp64 foo"
>>> if there is one.
>>
>> As to the latter - of course. But how does the latter constrain the former in any
>> way? I'm sorry to say that, but you make statements without actually providing
>> explanations. Yet it's the explanation that's crucial here if you want to
>> convince me of (or at least make me understand) your view of the situation. I for
>> one did explain why I think we'd better support both forms (and you demonstrated
>> that I'm right there by the two contradicting initial replies of yours).
> 
> In AT&T syntax, foo is an address operand and $foo is an immediate
> operand.  Since jmpabs takes an immediate operand, only $foo is valid.

And where is it said that the operand is an immediate one? How's the doc
different in this regard from CALL / JMP / XBEGIN (with displacement)? It
says "target64", and validly so. That doesn't constrain things to immediate
or displacement. The spec doesn't even have a need to spell out how the
operand is to be expressed in assembly sources. If that was to be spelled
out, it would be in an assembly language spec, which simply doesn't exist
(in an up-to-date form, where new insns could be expected to be added as
they appear). Plus even if such a doc existed, we could _still_ decide to
support an alternative form as extension.

In assembly source it doesn't really matter whether the eventual encoding
uses a relative or absolute address. I.e.

	jmp	func
	call	func
	jmpabs	func

are quite a bit more natural / consistent than if the JMPABS was _required_
to have a $ prefixed to its operand. And again - for people preferring it
that way, we still _allow_ that form with $.

Jan
  

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, October 9, 2024 4:28 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 09.10.2024 09:45, Hu, Lin1 wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Wednesday, October 9, 2024 3:42 PM
> >>
> >> On 09.10.2024 09:33, H.J. Lu wrote:
> >>> It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be "jmp64
> foo"
> >>> if there is one.
> >>
> >> As to the latter - of course. But how does the latter constrain the
> >> former in any way? I'm sorry to say that, but you make statements
> >> without actually providing explanations. Yet it's the explanation
> >> that's crucial here if you want to convince me of (or at least make
> >> me understand) your view of the situation. I for one did explain why
> >> I think we'd better support both forms (and you demonstrated that I'm
> >> right there by the two contradicting initial replies of yours).
> >
> > From doc and the results of our previous discussions with relevant colleagues,
> the operand should be a 64-bit immediate operand about instruction encoding.
> Maybe they have the same bytecode, but I don't think we should confuse them,
> we should make it clear to anyone who sees this instruction that it's an
> immediate operand.
> 
> Same question as to H.J.: Why? What's wrong with it not requiring the $ in AT&T
> syntax and, worse, the "offset" in Intel syntax when a symbol is referenced?
> People wanting to use the immediate form can very well do so.
> People preferring the displacement form would better not be forced to use a
> form they're not comfortable with. Unless - as expressed before - there actually
> is a reason to enforce such a constraint. Yet so far I've not seen any such reason
> being spelled out.
> 

If we have another instruction like "jmpabs foo" in the future, but its opcode isn't A1, how does binutils distinguish between them?

BRs
Lin
  

On 09.10.2024 10:41, Hu, Lin1 wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Wednesday, October 9, 2024 4:28 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 09.10.2024 09:45, Hu, Lin1 wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Wednesday, October 9, 2024 3:42 PM
>>>>
>>>> On 09.10.2024 09:33, H.J. Lu wrote:
>>>>> It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be "jmp64
>> foo"
>>>>> if there is one.
>>>>
>>>> As to the latter - of course. But how does the latter constrain the
>>>> former in any way? I'm sorry to say that, but you make statements
>>>> without actually providing explanations. Yet it's the explanation
>>>> that's crucial here if you want to convince me of (or at least make
>>>> me understand) your view of the situation. I for one did explain why
>>>> I think we'd better support both forms (and you demonstrated that I'm
>>>> right there by the two contradicting initial replies of yours).
>>>
>>> From doc and the results of our previous discussions with relevant colleagues,
>> the operand should be a 64-bit immediate operand about instruction encoding.
>> Maybe they have the same bytecode, but I don't think we should confuse them,
>> we should make it clear to anyone who sees this instruction that it's an
>> immediate operand.
>>
>> Same question as to H.J.: Why? What's wrong with it not requiring the $ in AT&T
>> syntax and, worse, the "offset" in Intel syntax when a symbol is referenced?
>> People wanting to use the immediate form can very well do so.
>> People preferring the displacement form would better not be forced to use a
>> form they're not comfortable with. Unless - as expressed before - there actually
>> is a reason to enforce such a constraint. Yet so far I've not seen any such reason
>> being spelled out.
> 
> If we have another instruction like "jmpabs foo" in the future, but its opcode isn't A1, how does binutils distinguish between them?

I discussed this in an earlier reply. If you have concerns there, please describe
what that supposed insn form would do. It can't be a relative direct jump (or else
the "abs" in the mnemonic was wrong), and if it was a relative indirect one, it'll
require a * prefix on its operand to be consistent with other indirect branches.
Plus, as explained earlier, that would then be exactly the same as "jmp *foo", so
there's hardly any reason such a redundant encoding would ever be added.

Jan
  

On Wed, Oct 9, 2024 at 4:48 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 09.10.2024 10:41, Hu, Lin1 wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Wednesday, October 9, 2024 4:28 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 09.10.2024 09:45, Hu, Lin1 wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: Wednesday, October 9, 2024 3:42 PM
> >>>>
> >>>> On 09.10.2024 09:33, H.J. Lu wrote:
> >>>>> It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be "jmp64
> >> foo"
> >>>>> if there is one.
> >>>>
> >>>> As to the latter - of course. But how does the latter constrain the
> >>>> former in any way? I'm sorry to say that, but you make statements
> >>>> without actually providing explanations. Yet it's the explanation
> >>>> that's crucial here if you want to convince me of (or at least make
> >>>> me understand) your view of the situation. I for one did explain why
> >>>> I think we'd better support both forms (and you demonstrated that I'm
> >>>> right there by the two contradicting initial replies of yours).
> >>>
> >>> From doc and the results of our previous discussions with relevant colleagues,
> >> the operand should be a 64-bit immediate operand about instruction encoding.
> >> Maybe they have the same bytecode, but I don't think we should confuse them,
> >> we should make it clear to anyone who sees this instruction that it's an
> >> immediate operand.
> >>
> >> Same question as to H.J.: Why? What's wrong with it not requiring the $ in AT&T
> >> syntax and, worse, the "offset" in Intel syntax when a symbol is referenced?
> >> People wanting to use the immediate form can very well do so.
> >> People preferring the displacement form would better not be forced to use a
> >> form they're not comfortable with. Unless - as expressed before - there actually
> >> is a reason to enforce such a constraint. Yet so far I've not seen any such reason
> >> being spelled out.
> >
> > If we have another instruction like "jmpabs foo" in the future, but its opcode isn't A1, how does binutils distinguish between them?
>
> I discussed this in an earlier reply. If you have concerns there, please describe
> what that supposed insn form would do. It can't be a relative direct jump (or else
> the "abs" in the mnemonic was wrong), and if it was a relative indirect one, it'll
> require a * prefix on its operand to be consistent with other indirect branches.
> Plus, as explained earlier, that would then be exactly the same as "jmp *foo", so
> there's hardly any reason such a redundant encoding would ever be added.
>

imm64 in jmpabs is the same type as imm64 in movabs.  imm64 should be
expressed as "$symbol" in AT&T syntax.
  

On 09.10.2024 11:52, H.J. Lu wrote:
> On Wed, Oct 9, 2024 at 4:48 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 09.10.2024 10:41, Hu, Lin1 wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Wednesday, October 9, 2024 4:28 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 09.10.2024 09:45, Hu, Lin1 wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>> Sent: Wednesday, October 9, 2024 3:42 PM
>>>>>>
>>>>>> On 09.10.2024 09:33, H.J. Lu wrote:
>>>>>>> It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be "jmp64
>>>> foo"
>>>>>>> if there is one.
>>>>>>
>>>>>> As to the latter - of course. But how does the latter constrain the
>>>>>> former in any way? I'm sorry to say that, but you make statements
>>>>>> without actually providing explanations. Yet it's the explanation
>>>>>> that's crucial here if you want to convince me of (or at least make
>>>>>> me understand) your view of the situation. I for one did explain why
>>>>>> I think we'd better support both forms (and you demonstrated that I'm
>>>>>> right there by the two contradicting initial replies of yours).
>>>>>
>>>>> From doc and the results of our previous discussions with relevant colleagues,
>>>> the operand should be a 64-bit immediate operand about instruction encoding.
>>>> Maybe they have the same bytecode, but I don't think we should confuse them,
>>>> we should make it clear to anyone who sees this instruction that it's an
>>>> immediate operand.
>>>>
>>>> Same question as to H.J.: Why? What's wrong with it not requiring the $ in AT&T
>>>> syntax and, worse, the "offset" in Intel syntax when a symbol is referenced?
>>>> People wanting to use the immediate form can very well do so.
>>>> People preferring the displacement form would better not be forced to use a
>>>> form they're not comfortable with. Unless - as expressed before - there actually
>>>> is a reason to enforce such a constraint. Yet so far I've not seen any such reason
>>>> being spelled out.
>>>
>>> If we have another instruction like "jmpabs foo" in the future, but its opcode isn't A1, how does binutils distinguish between them?
>>
>> I discussed this in an earlier reply. If you have concerns there, please describe
>> what that supposed insn form would do. It can't be a relative direct jump (or else
>> the "abs" in the mnemonic was wrong), and if it was a relative indirect one, it'll
>> require a * prefix on its operand to be consistent with other indirect branches.
>> Plus, as explained earlier, that would then be exactly the same as "jmp *foo", so
>> there's hardly any reason such a redundant encoding would ever be added.
>>
> 
> imm64 in jmpabs is the same type as imm64 in movabs.  imm64 should be
> expressed as "$symbol" in AT&T syntax.

Which of the two MOVABS forms do you mean? The A0/A1 encoding doesn't use
imm64 but moffs, and clearly that's closer to JMPABS (same opcode,
different just by REX/REX2) than the B8...BF encodings.

Jan
  

On Wed, Oct 9, 2024, 6:16 PM Jan Beulich <jbeulich@suse.com> wrote:

> On 09.10.2024 11:52, H.J. Lu wrote:
> > On Wed, Oct 9, 2024 at 4:48 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 09.10.2024 10:41, Hu, Lin1 wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: Wednesday, October 9, 2024 4:28 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 09.10.2024 09:45, Hu, Lin1 wrote:
> >>>>>> -----Original Message-----
> >>>>>> From: Jan Beulich <jbeulich@suse.com>
> >>>>>> Sent: Wednesday, October 9, 2024 3:42 PM
> >>>>>>
> >>>>>> On 09.10.2024 09:33, H.J. Lu wrote:
> >>>>>>> It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be
> "jmp64
> >>>> foo"
> >>>>>>> if there is one.
> >>>>>>
> >>>>>> As to the latter - of course. But how does the latter constrain the
> >>>>>> former in any way? I'm sorry to say that, but you make statements
> >>>>>> without actually providing explanations. Yet it's the explanation
> >>>>>> that's crucial here if you want to convince me of (or at least make
> >>>>>> me understand) your view of the situation. I for one did explain why
> >>>>>> I think we'd better support both forms (and you demonstrated that
> I'm
> >>>>>> right there by the two contradicting initial replies of yours).
> >>>>>
> >>>>> From doc and the results of our previous discussions with relevant
> colleagues,
> >>>> the operand should be a 64-bit immediate operand about instruction
> encoding.
> >>>> Maybe they have the same bytecode, but I don't think we should
> confuse them,
> >>>> we should make it clear to anyone who sees this instruction that it's
> an
> >>>> immediate operand.
> >>>>
> >>>> Same question as to H.J.: Why? What's wrong with it not requiring the
> $ in AT&T
> >>>> syntax and, worse, the "offset" in Intel syntax when a symbol is
> referenced?
> >>>> People wanting to use the immediate form can very well do so.
> >>>> People preferring the displacement form would better not be forced to
> use a
> >>>> form they're not comfortable with. Unless - as expressed before -
> there actually
> >>>> is a reason to enforce such a constraint. Yet so far I've not seen
> any such reason
> >>>> being spelled out.
> >>>
> >>> If we have another instruction like "jmpabs foo" in the future, but
> its opcode isn't A1, how does binutils distinguish between them?
> >>
> >> I discussed this in an earlier reply. If you have concerns there,
> please describe
> >> what that supposed insn form would do. It can't be a relative direct
> jump (or else
> >> the "abs" in the mnemonic was wrong), and if it was a relative indirect
> one, it'll
> >> require a * prefix on its operand to be consistent with other indirect
> branches.
> >> Plus, as explained earlier, that would then be exactly the same as "jmp
> *foo", so
> >> there's hardly any reason such a redundant encoding would ever be added.
> >>
> >
> > imm64 in jmpabs is the same type as imm64 in movabs.  imm64 should be
> > expressed as "$symbol" in AT&T syntax.
>
> Which of the two MOVABS forms do you mean? The A0/A1 encoding


The one with the imm64 entry.

doesn't use
> imm64 but moffs, and clearly that's closer to JMPABS (same opcode,
> different just by REX/REX2) than the B8...BF encodings.
>
> Jan
>
>
  

On 09.10.2024 12:51, H.J. Lu wrote:
> On Wed, Oct 9, 2024, 6:16 PM Jan Beulich <jbeulich@suse.com> wrote:
> 
>> On 09.10.2024 11:52, H.J. Lu wrote:
>>> On Wed, Oct 9, 2024 at 4:48 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 09.10.2024 10:41, Hu, Lin1 wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>> Sent: Wednesday, October 9, 2024 4:28 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 09.10.2024 09:45, Hu, Lin1 wrote:
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>>>> Sent: Wednesday, October 9, 2024 3:42 PM
>>>>>>>>
>>>>>>>> On 09.10.2024 09:33, H.J. Lu wrote:
>>>>>>>>> It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be
>> "jmp64
>>>>>> foo"
>>>>>>>>> if there is one.
>>>>>>>>
>>>>>>>> As to the latter - of course. But how does the latter constrain the
>>>>>>>> former in any way? I'm sorry to say that, but you make statements
>>>>>>>> without actually providing explanations. Yet it's the explanation
>>>>>>>> that's crucial here if you want to convince me of (or at least make
>>>>>>>> me understand) your view of the situation. I for one did explain why
>>>>>>>> I think we'd better support both forms (and you demonstrated that
>> I'm
>>>>>>>> right there by the two contradicting initial replies of yours).
>>>>>>>
>>>>>>> From doc and the results of our previous discussions with relevant
>> colleagues,
>>>>>> the operand should be a 64-bit immediate operand about instruction
>> encoding.
>>>>>> Maybe they have the same bytecode, but I don't think we should
>> confuse them,
>>>>>> we should make it clear to anyone who sees this instruction that it's
>> an
>>>>>> immediate operand.
>>>>>>
>>>>>> Same question as to H.J.: Why? What's wrong with it not requiring the
>> $ in AT&T
>>>>>> syntax and, worse, the "offset" in Intel syntax when a symbol is
>> referenced?
>>>>>> People wanting to use the immediate form can very well do so.
>>>>>> People preferring the displacement form would better not be forced to
>> use a
>>>>>> form they're not comfortable with. Unless - as expressed before -
>> there actually
>>>>>> is a reason to enforce such a constraint. Yet so far I've not seen
>> any such reason
>>>>>> being spelled out.
>>>>>
>>>>> If we have another instruction like "jmpabs foo" in the future, but
>> its opcode isn't A1, how does binutils distinguish between them?
>>>>
>>>> I discussed this in an earlier reply. If you have concerns there,
>> please describe
>>>> what that supposed insn form would do. It can't be a relative direct
>> jump (or else
>>>> the "abs" in the mnemonic was wrong), and if it was a relative indirect
>> one, it'll
>>>> require a * prefix on its operand to be consistent with other indirect
>> branches.
>>>> Plus, as explained earlier, that would then be exactly the same as "jmp
>> *foo", so
>>>> there's hardly any reason such a redundant encoding would ever be added.
>>>>
>>>
>>> imm64 in jmpabs is the same type as imm64 in movabs.  imm64 should be
>>> expressed as "$symbol" in AT&T syntax.
>>
>> Which of the two MOVABS forms do you mean? The A0/A1 encoding
> 
> The one with the imm64 entry.

Come on, don't have me ask for every detail. Why would it be that one to
compare with and not ...

> doesn't use
>> imm64 but moffs, and clearly that's closer to JMPABS (same opcode,
>> different just by REX/REX2)

... this other one?

Just to repeat - it doesn't help move the discussion forward if you merely
make statements, without backing them up with respective reasoning. I
can't help getting the impression that you simply can't justify what you
want, and it's instead merely a subjective choice of yours.

>> than the B8...BF encodings.

Jan
  

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, October 9, 2024 7:40 PM
> To: H.J. Lu <hjl.tools@gmail.com>
> Cc: Hu, Lin1 <lin1.hu@intel.com>; Binutils <binutils@sourceware.org>; Cui, Lili
> <lili.cui@intel.com>
> Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in assembler
> 
> On 09.10.2024 12:51, H.J. Lu wrote:
> > On Wed, Oct 9, 2024, 6:16 PM Jan Beulich <jbeulich@suse.com> wrote:
> >
> >> On 09.10.2024 11:52, H.J. Lu wrote:
> >>> On Wed, Oct 9, 2024 at 4:48 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 09.10.2024 10:41, Hu, Lin1 wrote:
> >>>>>> -----Original Message-----
> >>>>>> From: Jan Beulich <jbeulich@suse.com>
> >>>>>> Sent: Wednesday, October 9, 2024 4:28 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 09.10.2024 09:45, Hu, Lin1 wrote:
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Jan Beulich <jbeulich@suse.com>
> >>>>>>>> Sent: Wednesday, October 9, 2024 3:42 PM
> >>>>>>>>
> >>>>>>>> On 09.10.2024 09:33, H.J. Lu wrote:
> >>>>>>>>> It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be
> >> "jmp64
> >>>>>> foo"
> >>>>>>>>> if there is one.
> >>>>>>>>
> >>>>>>>> As to the latter - of course. But how does the latter constrain
> >>>>>>>> the former in any way? I'm sorry to say that, but you make
> >>>>>>>> statements without actually providing explanations. Yet it's
> >>>>>>>> the explanation that's crucial here if you want to convince me
> >>>>>>>> of (or at least make me understand) your view of the situation.
> >>>>>>>> I for one did explain why I think we'd better support both
> >>>>>>>> forms (and you demonstrated that
> >> I'm
> >>>>>>>> right there by the two contradicting initial replies of yours).
> >>>>>>>
> >>>>>>> From doc and the results of our previous discussions with
> >>>>>>> relevant
> >> colleagues,
> >>>>>> the operand should be a 64-bit immediate operand about
> >>>>>> instruction
> >> encoding.
> >>>>>> Maybe they have the same bytecode, but I don't think we should
> >> confuse them,
> >>>>>> we should make it clear to anyone who sees this instruction that
> >>>>>> it's
> >> an
> >>>>>> immediate operand.
> >>>>>>
> >>>>>> Same question as to H.J.: Why? What's wrong with it not requiring
> >>>>>> the
> >> $ in AT&T
> >>>>>> syntax and, worse, the "offset" in Intel syntax when a symbol is
> >> referenced?
> >>>>>> People wanting to use the immediate form can very well do so.
> >>>>>> People preferring the displacement form would better not be
> >>>>>> forced to
> >> use a
> >>>>>> form they're not comfortable with. Unless - as expressed before -
> >> there actually
> >>>>>> is a reason to enforce such a constraint. Yet so far I've not
> >>>>>> seen
> >> any such reason
> >>>>>> being spelled out.
> >>>>>
> >>>>> If we have another instruction like "jmpabs foo" in the future,
> >>>>> but
> >> its opcode isn't A1, how does binutils distinguish between them?
> >>>>
> >>>> I discussed this in an earlier reply. If you have concerns there,
> >> please describe
> >>>> what that supposed insn form would do. It can't be a relative
> >>>> direct
> >> jump (or else
> >>>> the "abs" in the mnemonic was wrong), and if it was a relative
> >>>> indirect
> >> one, it'll
> >>>> require a * prefix on its operand to be consistent with other
> >>>> indirect
> >> branches.
> >>>> Plus, as explained earlier, that would then be exactly the same as
> >>>> "jmp
> >> *foo", so
> >>>> there's hardly any reason such a redundant encoding would ever be added.
> >>>>
> >>>
> >>> imm64 in jmpabs is the same type as imm64 in movabs.  imm64 should
> >>> be expressed as "$symbol" in AT&T syntax.
> >>
> >> Which of the two MOVABS forms do you mean? The A0/A1 encoding
> >
> > The one with the imm64 entry.
> 
> Come on, don't have me ask for every detail. Why would it be that one to
> compare with and not ...
> 
> > doesn't use
> >> imm64 but moffs, and clearly that's closer to JMPABS (same opcode,
> >> different just by REX/REX2)
> 
> ... this other one?
> 
> Just to repeat - it doesn't help move the discussion forward if you merely make
> statements, without backing them up with respective reasoning. I can't help
> getting the impression that you simply can't justify what you want, and it's
> instead merely a subjective choice of yours.
> 
> >> than the B8...BF encodings.
> 

I don't think linker currently supports the following forms:
label:
	...
	jmpabs label

Same thing we discussed earlier, it's pointless to support this format now. And for the form that uses label, maybe we can consider let linker to convert 'jmp label''s encoding to jmpabs's. For gas, even if the likelihood of a new instruction like 'jmpabs 0x521515' appearing is small, that's no reason for us to accept this usage; we think it's safer to let the linker support it.

BRs,
Lin
  

> -----Original Message-----
> From: Hu, Lin1
> Sent: Thursday, October 10, 2024 9:54 AM
> To: 'Jan Beulich' <jbeulich@suse.com>; H.J. Lu <hjl.tools@gmail.com>
> Cc: Binutils <binutils@sourceware.org>; Cui, Lili <lili.cui@intel.com>
> Subject: RE: [PATCH 2/2] x86/APX: support JMPABS also in assembler
> 
> > -----Original Message-----
> > From: Jan Beulich <jbeulich@suse.com>
> > Sent: Wednesday, October 9, 2024 7:40 PM
> > To: H.J. Lu <hjl.tools@gmail.com>
> > Cc: Hu, Lin1 <lin1.hu@intel.com>; Binutils <binutils@sourceware.org>;
> > Cui, Lili <lili.cui@intel.com>
> > Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in assembler
> >
> > On 09.10.2024 12:51, H.J. Lu wrote:
> > > On Wed, Oct 9, 2024, 6:16 PM Jan Beulich <jbeulich@suse.com> wrote:
> > >
> > >> On 09.10.2024 11:52, H.J. Lu wrote:
> > >>> On Wed, Oct 9, 2024 at 4:48 PM Jan Beulich <jbeulich@suse.com> wrote:
> > >>>>
> > >>>> On 09.10.2024 10:41, Hu, Lin1 wrote:
> > >>>>>> -----Original Message-----
> > >>>>>> From: Jan Beulich <jbeulich@suse.com>
> > >>>>>> Sent: Wednesday, October 9, 2024 4:28 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 09.10.2024 09:45, Hu, Lin1 wrote:
> > >>>>>>>> -----Original Message-----
> > >>>>>>>> From: Jan Beulich <jbeulich@suse.com>
> > >>>>>>>> Sent: Wednesday, October 9, 2024 3:42 PM
> > >>>>>>>>
> > >>>>>>>> On 09.10.2024 09:33, H.J. Lu wrote:
> > >>>>>>>>> It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be
> > >> "jmp64
> > >>>>>> foo"
> > >>>>>>>>> if there is one.
> > >>>>>>>>
> > >>>>>>>> As to the latter - of course. But how does the latter
> > >>>>>>>> constrain the former in any way? I'm sorry to say that, but
> > >>>>>>>> you make statements without actually providing explanations.
> > >>>>>>>> Yet it's the explanation that's crucial here if you want to
> > >>>>>>>> convince me of (or at least make me understand) your view of the
> situation.
> > >>>>>>>> I for one did explain why I think we'd better support both
> > >>>>>>>> forms (and you demonstrated that
> > >> I'm
> > >>>>>>>> right there by the two contradicting initial replies of yours).
> > >>>>>>>
> > >>>>>>> From doc and the results of our previous discussions with
> > >>>>>>> relevant
> > >> colleagues,
> > >>>>>> the operand should be a 64-bit immediate operand about
> > >>>>>> instruction
> > >> encoding.
> > >>>>>> Maybe they have the same bytecode, but I don't think we should
> > >> confuse them,
> > >>>>>> we should make it clear to anyone who sees this instruction
> > >>>>>> that it's
> > >> an
> > >>>>>> immediate operand.
> > >>>>>>
> > >>>>>> Same question as to H.J.: Why? What's wrong with it not
> > >>>>>> requiring the
> > >> $ in AT&T
> > >>>>>> syntax and, worse, the "offset" in Intel syntax when a symbol
> > >>>>>> is
> > >> referenced?
> > >>>>>> People wanting to use the immediate form can very well do so.
> > >>>>>> People preferring the displacement form would better not be
> > >>>>>> forced to
> > >> use a
> > >>>>>> form they're not comfortable with. Unless - as expressed before
> > >>>>>> -
> > >> there actually
> > >>>>>> is a reason to enforce such a constraint. Yet so far I've not
> > >>>>>> seen
> > >> any such reason
> > >>>>>> being spelled out.
> > >>>>>
> > >>>>> If we have another instruction like "jmpabs foo" in the future,
> > >>>>> but
> > >> its opcode isn't A1, how does binutils distinguish between them?
> > >>>>
> > >>>> I discussed this in an earlier reply. If you have concerns there,
> > >> please describe
> > >>>> what that supposed insn form would do. It can't be a relative
> > >>>> direct
> > >> jump (or else
> > >>>> the "abs" in the mnemonic was wrong), and if it was a relative
> > >>>> indirect
> > >> one, it'll
> > >>>> require a * prefix on its operand to be consistent with other
> > >>>> indirect
> > >> branches.
> > >>>> Plus, as explained earlier, that would then be exactly the same
> > >>>> as "jmp
> > >> *foo", so
> > >>>> there's hardly any reason such a redundant encoding would ever be
> added.
> > >>>>
> > >>>
> > >>> imm64 in jmpabs is the same type as imm64 in movabs.  imm64 should
> > >>> be expressed as "$symbol" in AT&T syntax.
> > >>
> > >> Which of the two MOVABS forms do you mean? The A0/A1 encoding
> > >
> > > The one with the imm64 entry.
> >
> > Come on, don't have me ask for every detail. Why would it be that one
> > to compare with and not ...
> >
> > > doesn't use
> > >> imm64 but moffs, and clearly that's closer to JMPABS (same opcode,
> > >> different just by REX/REX2)
> >
> > ... this other one?
> >
> > Just to repeat - it doesn't help move the discussion forward if you
> > merely make statements, without backing them up with respective
> > reasoning. I can't help getting the impression that you simply can't
> > justify what you want, and it's instead merely a subjective choice of yours.
> >
> > >> than the B8...BF encodings.
> >
> 
> I don't think linker currently supports the following forms:
> label:
> 	...
> 	jmpabs label
> 
> Same thing we discussed earlier, it's pointless to support this format now. And
> for the form that uses label, maybe we can consider let linker to convert 'jmp
> label''s encoding to jmpabs's. For gas, even if the likelihood of a new instruction
> like 'jmpabs 0x521515' appearing is small, that's no reason for us to accept this
> usage; we think it's safer to let the linker support it.
> 

And I think 'movabs moffs64, %rax' and 'movabs imm64, %rax' are two different instructions, they have different opcode.
According to spec, jmpabs is closer to 'movabs imm64, %rax', because jmpabs only accept imm64. 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.

BRs,
Lin
  

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, October 9, 2024 7:40 PM
> To: H.J. Lu <hjl.tools@gmail.com>
> Cc: Hu, Lin1 <lin1.hu@intel.com>; Binutils <binutils@sourceware.org>; Cui, Lili
> <lili.cui@intel.com>
> Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in assembler
> 
> On 09.10.2024 12:51, H.J. Lu wrote:
> > On Wed, Oct 9, 2024, 6:16 PM Jan Beulich <jbeulich@suse.com> wrote:
> >
> >> On 09.10.2024 11:52, H.J. Lu wrote:
> >>> On Wed, Oct 9, 2024 at 4:48 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 09.10.2024 10:41, Hu, Lin1 wrote:
> >>>>>> -----Original Message-----
> >>>>>> From: Jan Beulich <jbeulich@suse.com>
> >>>>>> Sent: Wednesday, October 9, 2024 4:28 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 09.10.2024 09:45, Hu, Lin1 wrote:
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Jan Beulich <jbeulich@suse.com>
> >>>>>>>> Sent: Wednesday, October 9, 2024 3:42 PM
> >>>>>>>>
> >>>>>>>> On 09.10.2024 09:33, H.J. Lu wrote:
> >>>>>>>>> It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be
> >> "jmp64
> >>>>>> foo"
> >>>>>>>>> if there is one.
> >>>>>>>>
> >>>>>>>> As to the latter - of course. But how does the latter constrain
> >>>>>>>> the former in any way? I'm sorry to say that, but you make
> >>>>>>>> statements without actually providing explanations. Yet it's
> >>>>>>>> the explanation that's crucial here if you want to convince me
> >>>>>>>> of (or at least make me understand) your view of the situation.
> >>>>>>>> I for one did explain why I think we'd better support both
> >>>>>>>> forms (and you demonstrated that
> >> I'm
> >>>>>>>> right there by the two contradicting initial replies of yours).
> >>>>>>>
> >>>>>>> From doc and the results of our previous discussions with
> >>>>>>> relevant
> >> colleagues,
> >>>>>> the operand should be a 64-bit immediate operand about
> >>>>>> instruction
> >> encoding.
> >>>>>> Maybe they have the same bytecode, but I don't think we should
> >> confuse them,
> >>>>>> we should make it clear to anyone who sees this instruction that
> >>>>>> it's
> >> an
> >>>>>> immediate operand.
> >>>>>>
> >>>>>> Same question as to H.J.: Why? What's wrong with it not requiring
> >>>>>> the
> >> $ in AT&T
> >>>>>> syntax and, worse, the "offset" in Intel syntax when a symbol is
> >> referenced?
> >>>>>> People wanting to use the immediate form can very well do so.
> >>>>>> People preferring the displacement form would better not be
> >>>>>> forced to
> >> use a
> >>>>>> form they're not comfortable with. Unless - as expressed before -
> >> there actually
> >>>>>> is a reason to enforce such a constraint. Yet so far I've not
> >>>>>> seen
> >> any such reason
> >>>>>> being spelled out.
> >>>>>
> >>>>> If we have another instruction like "jmpabs foo" in the future,
> >>>>> but
> >> its opcode isn't A1, how does binutils distinguish between them?
> >>>>
> >>>> I discussed this in an earlier reply. If you have concerns there,
> >> please describe
> >>>> what that supposed insn form would do. It can't be a relative
> >>>> direct
> >> jump (or else
> >>>> the "abs" in the mnemonic was wrong), and if it was a relative
> >>>> indirect
> >> one, it'll
> >>>> require a * prefix on its operand to be consistent with other
> >>>> indirect
> >> branches.
> >>>> Plus, as explained earlier, that would then be exactly the same as
> >>>> "jmp
> >> *foo", so
> >>>> there's hardly any reason such a redundant encoding would ever be added.
> >>>>
> >>>
> >>> imm64 in jmpabs is the same type as imm64 in movabs.  imm64 should
> >>> be expressed as "$symbol" in AT&T syntax.
> >>
> >> Which of the two MOVABS forms do you mean? The A0/A1 encoding
> >
> > The one with the imm64 entry.
> 

'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. supporting both formats will confuse users. Is this an immediate value or an offset? But in fact, this is an immediate value. For the unknown future, we should not occupy this expression, movabs also support immediate and offset with different opcode.

movabs, 0xa0, x64, D|W|CheckOperandSize|No_sSuf, { Disp64|Unspecified|Byte|Word|Dword|Qword, Acc|Byte|Word|Dword|Qword }
movabs, 0xb8, x64, No_bSuf|No_wSuf|No_lSuf|No_sSuf, { Imm64, Reg64 }


Lili.

> Come on, don't have me ask for every detail. Why would it be that one to
> compare with and not ...
> 
> > doesn't use
> >> imm64 but moffs, and clearly that's closer to JMPABS (same opcode,
> >> different just by REX/REX2)
> 
> ... this other one?
> 
> Just to repeat - it doesn't help move the discussion forward if you merely make
> statements, without backing them up with respective reasoning. I can't help
> getting the impression that you simply can't justify what you want, and it's
> instead merely a subjective choice of yours.
> 
> >> than the B8...BF encodings.
> 
> Jan
  

On 10.10.2024 03:53, Hu, Lin1 wrote:
> I don't think linker currently supports the following forms:
> label:
> 	...
> 	jmpabs label

Why would it not support this? It doesn't care at all what insn it is; all
it cares about is the associated relocation (R_X86_64_64 for ELF). And ...

> Same thing we discussed earlier, it's pointless to support this format now. And for the form that uses label, maybe we can consider let linker to convert 'jmp label''s encoding to jmpabs's. For gas, even if the likelihood of a new instruction like 'jmpabs 0x521515' appearing is small, that's no reason for us to accept this usage; we think it's safer to let the linker support it.

... how does the linker come into the picture here in the first place?

Jan
  

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.

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.

> 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.

Jan
  

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

> 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.

> For the unknown future, we should not occupy this expression, movabs also support immediate and offset with different opcode.
> 
> movabs, 0xa0, x64, D|W|CheckOperandSize|No_sSuf, { Disp64|Unspecified|Byte|Word|Dword|Qword, Acc|Byte|Word|Dword|Qword }
> movabs, 0xb8, x64, No_bSuf|No_wSuf|No_lSuf|No_sSuf, { Imm64, Reg64 }

Right, and necessarily so. Note however that the SDM doesn't know MOVABS
at all. It's something gas invented (or borrowed from some other
assembler); MASM for example doesn't appear to know of MOVABS at all.

Note however that I previously addressed this argument: A similar 2nd
flavor of JMPABS is simply unnecessary, as "jmp *symbol" already fulfills
that purpose. And I can't really see you expecting for just JMPABS (and
no other instruction) to gain an indirect form allowing for a 64-bit
displacement. Plus, as also said before, that would then still be
"jmpabs *symbol", i.e. distinguishable from the non-immediate form I'm
proposing to permit. The *, after all, was invented to be able to tell
apart direct and indirect branches.

Jan
  

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, October 10, 2024 3:05 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 03:53, Hu, Lin1 wrote:
> > I don't think linker currently supports the following forms:
> > label:
> > 	...
> > 	jmpabs label
> 
> Why would it not support this? It doesn't care at all what insn it is; all
> it cares about is the associated relocation (R_X86_64_64 for ELF). And ...
>

I'm not familiar with this part. Does assembler definitely generate R_X86_64_64 rather than R_X86_64_GOTOFF64 or R_X86_64_PLTOFF64?
 
>
> > Same thing we discussed earlier, it's pointless to support this format now. And
> for the form that uses label, maybe we can consider let linker to convert 'jmp
> label''s encoding to jmpabs's. For gas, even if the likelihood of a new instruction
> like 'jmpabs 0x521515' appearing is small, that's no reason for us to accept this
> usage; we think it's safer to let the linker support it.
> 
> ... how does the linker come into the picture here in the first place?
> 

We think it's safer to extend the 'jmp label' functionality in the linker without any conflict with the documentation.

BRs,
Lin
  

> -----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.

>
> > 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 or immediate operand by the form of the operand rather than the "abs" in the mnemonic.

BRs,
Lin
  

On 10.10.2024 09:51, Hu, Lin1 wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Thursday, October 10, 2024 3:05 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 03:53, Hu, Lin1 wrote:
>>> I don't think linker currently supports the following forms:
>>> label:
>>> 	...
>>> 	jmpabs label
>>
>> Why would it not support this? It doesn't care at all what insn it is; all
>> it cares about is the associated relocation (R_X86_64_64 for ELF). And ...
> 
> I'm not familiar with this part. Does assembler definitely generate R_X86_64_64 rather than R_X86_64_GOTOFF64 or R_X86_64_PLTOFF64?

The assembler won't invent PLTOFF or GOTOFF when the source doesn't specify
it. If there were @pltoff or @gotoff operators (or whatever the correct forms
are) on the symbol, the assembler still has code to choke on wrong uses. I
didn't check though whether that would properly work here.

>>> Same thing we discussed earlier, it's pointless to support this format now. And
>> for the form that uses label, maybe we can consider let linker to convert 'jmp
>> label''s encoding to jmpabs's. For gas, even if the likelihood of a new instruction
>> like 'jmpabs 0x521515' appearing is small, that's no reason for us to accept this
>> usage; we think it's safer to let the linker support it.
>>
>> ... how does the linker come into the picture here in the first place?
> 
> We think it's safer to extend the 'jmp label' functionality in the linker without any conflict with the documentation.

That doesn't answer my question. Without that answered I'm also not understanding
your reply, I'm afraid.

Jan
  

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.

>>> 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.

Jan

> or immediate operand by the form of the operand rather than the "abs" in the mnemonic.
> 
> BRs,
> Lin
  

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, October 10, 2024 3:24 PM
> To: Cui, Lili <lili.cui@intel.com>
> Cc: Hu, Lin1 <lin1.hu@intel.com>; Binutils <binutils@sourceware.org>; H.J. Lu
> <hjl.tools@gmail.com>
> Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in assembler
> 
> 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.

> 
> > For the unknown future, we should not occupy this expression, movabs also
> support immediate and offset with different opcode.
> >
> > movabs, 0xa0, x64, D|W|CheckOperandSize|No_sSuf, {
> > Disp64|Unspecified|Byte|Word|Dword|Qword,
> Acc|Byte|Word|Dword|Qword }
> > movabs, 0xb8, x64, No_bSuf|No_wSuf|No_lSuf|No_sSuf, { Imm64, Reg64 }
> 
> Right, and necessarily so. Note however that the SDM doesn't know MOVABS
> at all. It's something gas invented (or borrowed from some other assembler);
> MASM for example doesn't appear to know of MOVABS at all.
> 

They are aliases for the following two mov. Here also reminds users that offset and immediate are different. Also assemblers and disassemblers should be consistent.

mov, 0xa0, x64, D|W|CheckOperandSize|No_sSuf, { Disp64|Unspecified|Byte|Word|Dword|Qword, Acc|Byte|Word|Dword|Qword }
mov, 0xb8, x64, No_bSuf|No_wSuf|No_lSuf|No_sSuf|Optimize, { Imm64, Reg64 }


Lili.

> Note however that I previously addressed this argument: A similar 2nd flavor
> of JMPABS is simply unnecessary, as "jmp *symbol" already fulfills that
> purpose. And I can't really see you expecting for just JMPABS (and no other
> instruction) to gain an indirect form allowing for a 64-bit displacement. Plus,
> as also said before, that would then still be "jmpabs *symbol", i.e.
> distinguishable from the non-immediate form I'm proposing to permit. The *,
> after all, was invented to be able to tell apart direct and indirect branches.
> 
> Jan
  

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.

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.

I also question your "Not supported in 64-bit mode."

>>> For the unknown future, we should not occupy this expression, movabs also
>> support immediate and offset with different opcode.
>>>
>>> movabs, 0xa0, x64, D|W|CheckOperandSize|No_sSuf, {
>>> Disp64|Unspecified|Byte|Word|Dword|Qword,
>> Acc|Byte|Word|Dword|Qword }
>>> movabs, 0xb8, x64, No_bSuf|No_wSuf|No_lSuf|No_sSuf, { Imm64, Reg64 }
>>
>> Right, and necessarily so. Note however that the SDM doesn't know MOVABS
>> at all. It's something gas invented (or borrowed from some other assembler);
>> MASM for example doesn't appear to know of MOVABS at all.
>>
> 
> They are aliases for the following two mov. Here also reminds users that offset and immediate are different.

I'm afraid I don't get what you're trying to express here. At the encoding
level there's no difference between moffs and imm64 (and e.g. opcode E8/E9's
disp32) - they're all immediate operands, merely with all different purposes.

With two MOV forms doing entirely different things, of course their (source)
representation needs to allow to actually pick between the two. Yet with
JMPABS we don't have two different forms, and we also don't need to be afraid
of a 2nd form appearing (as reasoned about before).

Hence what we end up with is an insn that has similarities with both MOVABS
forms. Leading to it being desirable to also support both forms.

> Also assemblers and disassemblers should be consistent.

Yes, to the extent possible. H.J. used to be putting it this way: What the
disassembler produces should assemble fine. This principle wouldn't be
violated if we supported both forms in the assembler. In fact in
https://sourceware.org/pipermail/binutils/2024-October/137152.html he
further indicated that making the disassembler choose between immediate
and displacement forms is an option. In that case it'll become imperative
for the assembler to support both forms, to fulfill the principle above.

Jan
  

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, October 10, 2024 4:25 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:05 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 03:53, Hu, Lin1 wrote:
> >>> I don't think linker currently supports the following forms:
> >>> label:
> >>> 	...
> >>> 	jmpabs label
> >>
> >> Why would it not support this? It doesn't care at all what insn it
> >> is; all it cares about is the associated relocation (R_X86_64_64 for ELF). And ...
> >
> > I'm not familiar with this part. Does assembler definitely generate
> R_X86_64_64 rather than R_X86_64_GOTOFF64 or R_X86_64_PLTOFF64?
> 
> The assembler won't invent PLTOFF or GOTOFF when the source doesn't specify
> it. If there were @pltoff or @gotoff operators (or whatever the correct forms
> are) on the symbol, the assembler still has code to choke on wrong uses. I didn't
> check though whether that would properly work here.
>

OK.
 
>
> >>> Same thing we discussed earlier, it's pointless to support this
> >>> format now. And
> >> for the form that uses label, maybe we can consider let linker to
> >> convert 'jmp label''s encoding to jmpabs's. For gas, even if the
> >> likelihood of a new instruction like 'jmpabs 0x521515' appearing is
> >> small, that's no reason for us to accept this usage; we think it's safer to let
> the linker support it.
> >>
> >> ... how does the linker come into the picture here in the first place?
> >
> > We think it's safer to extend the 'jmp label' functionality in the linker without
> any conflict with the documentation.
> 
> That doesn't answer my question. Without that answered I'm also not
> understanding your reply, I'm afraid.
> 

At first, we worried that the linker wouldn't support "jmpabs label" (This question may have already been answered). It's the root cause. And then from my viewpoint, "jmpabs  0x123" isn't allowed, so we consider use another method to let binutils's user use jmpabs, we think do a optimization in linker convert jmp to jmpabs is safer.

BRs,
Lin
  

> -----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 abstract 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.

BRs
Lin
  

On 10.10.2024 11:57, Hu, Lin1 wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Thursday, October 10, 2024 4:25 PM
>>
>> On 10.10.2024 09:51, Hu, Lin1 wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Thursday, October 10, 2024 3:05 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 03:53, Hu, Lin1 wrote:
>>>>> I don't think linker currently supports the following forms:
>>>>> label:
>>>>> 	...
>>>>> 	jmpabs label
>>>>
>>>> Why would it not support this? It doesn't care at all what insn it
>>>> is; all it cares about is the associated relocation (R_X86_64_64 for ELF). And ...
>>>
>>> I'm not familiar with this part. Does assembler definitely generate
>> R_X86_64_64 rather than R_X86_64_GOTOFF64 or R_X86_64_PLTOFF64?
>>
>> The assembler won't invent PLTOFF or GOTOFF when the source doesn't specify
>> it. If there were @pltoff or @gotoff operators (or whatever the correct forms
>> are) on the symbol, the assembler still has code to choke on wrong uses. I didn't
>> check though whether that would properly work here.
>>
> 
> OK.
>  
>>
>>>>> Same thing we discussed earlier, it's pointless to support this
>>>>> format now. And
>>>> for the form that uses label, maybe we can consider let linker to
>>>> convert 'jmp label''s encoding to jmpabs's. For gas, even if the
>>>> likelihood of a new instruction like 'jmpabs 0x521515' appearing is
>>>> small, that's no reason for us to accept this usage; we think it's safer to let
>> the linker support it.
>>>>
>>>> ... how does the linker come into the picture here in the first place?
>>>
>>> We think it's safer to extend the 'jmp label' functionality in the linker without
>> any conflict with the documentation.
>>
>> That doesn't answer my question. Without that answered I'm also not
>> understanding your reply, I'm afraid.
>>
> 
> At first, we worried that the linker wouldn't support "jmpabs label" (This question may have already been answered). It's the root cause. And then from my viewpoint, "jmpabs  0x123" isn't allowed, so we consider use another method to let binutils's user use jmpabs, we think do a optimization in linker convert jmp to jmpabs is safer.

Just to mention it: Unless you mean JMPABS -> JMP conversion, the conversion
you mention won't be possible without help by the assembler, as you would
need to reserve more bytes in the section in order to fit the longer insn.
Or maybe you're thinking of inserting "trampoline thunks" (iirc Arm64 calls
such "veneers"), themselves required to be within reach of the original JMP?

Jan
  

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, October 10, 2024 7:51 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 11:57, Hu, Lin1 wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Thursday, October 10, 2024 4:25 PM
> >>
> >> On 10.10.2024 09:51, Hu, Lin1 wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: Thursday, October 10, 2024 3:05 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 03:53, Hu, Lin1 wrote:
> >>>>> I don't think linker currently supports the following forms:
> >>>>> label:
> >>>>> 	...
> >>>>> 	jmpabs label
> >>>>
> >>>> Why would it not support this? It doesn't care at all what insn it
> >>>> is; all it cares about is the associated relocation (R_X86_64_64 for ELF).
> And ...
> >>>
> >>> I'm not familiar with this part. Does assembler definitely generate
> >> R_X86_64_64 rather than R_X86_64_GOTOFF64 or R_X86_64_PLTOFF64?
> >>
> >> The assembler won't invent PLTOFF or GOTOFF when the source doesn't
> >> specify it. If there were @pltoff or @gotoff operators (or whatever
> >> the correct forms
> >> are) on the symbol, the assembler still has code to choke on wrong
> >> uses. I didn't check though whether that would properly work here.
> >>
> >
> > OK.
> >
> >>
> >>>>> Same thing we discussed earlier, it's pointless to support this
> >>>>> format now. And
> >>>> for the form that uses label, maybe we can consider let linker to
> >>>> convert 'jmp label''s encoding to jmpabs's. For gas, even if the
> >>>> likelihood of a new instruction like 'jmpabs 0x521515' appearing is
> >>>> small, that's no reason for us to accept this usage; we think it's
> >>>> safer to let
> >> the linker support it.
> >>>>
> >>>> ... how does the linker come into the picture here in the first place?
> >>>
> >>> We think it's safer to extend the 'jmp label' functionality in the
> >>> linker without
> >> any conflict with the documentation.
> >>
> >> That doesn't answer my question. Without that answered I'm also not
> >> understanding your reply, I'm afraid.
> >>
> >
> > At first, we worried that the linker wouldn't support "jmpabs label" (This
> question may have already been answered). It's the root cause. And then from
> my viewpoint, "jmpabs  0x123" isn't allowed, so we consider use another
> method to let binutils's user use jmpabs, we think do a optimization in linker
> convert jmp to jmpabs is safer.
> 
> Just to mention it: Unless you mean JMPABS -> JMP conversion, the conversion
> you mention won't be possible without help by the assembler, as you would
> need to reserve more bytes in the section in order to fit the longer insn.
> Or maybe you're thinking of inserting "trampoline thunks" (iirc Arm64 calls such
> "veneers"), themselves required to be within reach of the original JMP?
> 

I didn't consider the code length issue at first. We should have a usage like "mov + jmp", I think we can consider do this conversion "mov + jmp -> jmpabs".

BRs,
Lin
  

On Fri, Oct 11, 2024, 9:41 AM Hu, Lin1 <lin1.hu@intel.com> wrote:

> > -----Original Message-----
> > From: Jan Beulich <jbeulich@suse.com>
> > Sent: Thursday, October 10, 2024 7:51 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 11:57, Hu, Lin1 wrote:
> > >> -----Original Message-----
> > >> From: Jan Beulich <jbeulich@suse.com>
> > >> Sent: Thursday, October 10, 2024 4:25 PM
> > >>
> > >> On 10.10.2024 09:51, Hu, Lin1 wrote:
> > >>>> -----Original Message-----
> > >>>> From: Jan Beulich <jbeulich@suse.com>
> > >>>> Sent: Thursday, October 10, 2024 3:05 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 03:53, Hu, Lin1 wrote:
> > >>>>> I don't think linker currently supports the following forms:
> > >>>>> label:
> > >>>>>         ...
> > >>>>>         jmpabs label
> > >>>>
> > >>>> Why would it not support this? It doesn't care at all what insn it
> > >>>> is; all it cares about is the associated relocation (R_X86_64_64
> for ELF).
> > And ...
> > >>>
> > >>> I'm not familiar with this part. Does assembler definitely generate
> > >> R_X86_64_64 rather than R_X86_64_GOTOFF64 or R_X86_64_PLTOFF64?
> > >>
> > >> The assembler won't invent PLTOFF or GOTOFF when the source doesn't
> > >> specify it. If there were @pltoff or @gotoff operators (or whatever
> > >> the correct forms
> > >> are) on the symbol, the assembler still has code to choke on wrong
> > >> uses. I didn't check though whether that would properly work here.
> > >>
> > >
> > > OK.
> > >
> > >>
> > >>>>> Same thing we discussed earlier, it's pointless to support this
> > >>>>> format now. And
> > >>>> for the form that uses label, maybe we can consider let linker to
> > >>>> convert 'jmp label''s encoding to jmpabs's. For gas, even if the
> > >>>> likelihood of a new instruction like 'jmpabs 0x521515' appearing is
> > >>>> small, that's no reason for us to accept this usage; we think it's
> > >>>> safer to let
> > >> the linker support it.
> > >>>>
> > >>>> ... how does the linker come into the picture here in the first
> place?
> > >>>
> > >>> We think it's safer to extend the 'jmp label' functionality in the
> > >>> linker without
> > >> any conflict with the documentation.
> > >>
> > >> That doesn't answer my question. Without that answered I'm also not
> > >> understanding your reply, I'm afraid.
> > >>
> > >
> > > At first, we worried that the linker wouldn't support "jmpabs label"
> (This
> > question may have already been answered). It's the root cause. And then
> from
> > my viewpoint, "jmpabs  0x123" isn't allowed, so we consider use another
> > method to let binutils's user use jmpabs, we think do a optimization in
> linker
> > convert jmp to jmpabs is safer.
> >
> > Just to mention it: Unless you mean JMPABS -> JMP conversion, the
> conversion
> > you mention won't be possible without help by the assembler, as you would
> > need to reserve more bytes in the section in order to fit the longer
> insn.
> > Or maybe you're thinking of inserting "trampoline thunks" (iirc Arm64
> calls such
> > "veneers"), themselves required to be within reach of the original JMP?
> >
>
> I didn't consider the code length issue at first. We should have a usage
> like "mov + jmp", I think we can consider do this conversion "mov + jmp ->
> jmpabs".
>

The reason we didn't add jmpabs to assembler is that
this instruction isn't designed for compilers nor assembler.
Its intended usages are for JITs.   Currently
glibc' ld.so will rewrite PLT entries with jmpabs if enabled
at runtime.
"jmpabs $foo" should be the only valid syntax.


> BRs,
> Lin
>
>
  

> 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. 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 also question your "Not supported in 64-bit mode."
> 

I copied it from JMP rel16,  JMP rel32 supports it.

Lili.
  

On 11.10.2024 03:49, H.J. Lu wrote:
> On Fri, Oct 11, 2024, 9:41 AM Hu, Lin1 <lin1.hu@intel.com> wrote:
> 
>>> -----Original Message-----
>>> From: Jan Beulich <jbeulich@suse.com>
>>> Sent: Thursday, October 10, 2024 7:51 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 11:57, Hu, Lin1 wrote:
>>>>> -----Original Message-----
>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>> Sent: Thursday, October 10, 2024 4:25 PM
>>>>>
>>>>> On 10.10.2024 09:51, Hu, Lin1 wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>>> Sent: Thursday, October 10, 2024 3:05 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 03:53, Hu, Lin1 wrote:
>>>>>>>> I don't think linker currently supports the following forms:
>>>>>>>> label:
>>>>>>>>         ...
>>>>>>>>         jmpabs label
>>>>>>>
>>>>>>> Why would it not support this? It doesn't care at all what insn it
>>>>>>> is; all it cares about is the associated relocation (R_X86_64_64
>> for ELF).
>>> And ...
>>>>>>
>>>>>> I'm not familiar with this part. Does assembler definitely generate
>>>>> R_X86_64_64 rather than R_X86_64_GOTOFF64 or R_X86_64_PLTOFF64?
>>>>>
>>>>> The assembler won't invent PLTOFF or GOTOFF when the source doesn't
>>>>> specify it. If there were @pltoff or @gotoff operators (or whatever
>>>>> the correct forms
>>>>> are) on the symbol, the assembler still has code to choke on wrong
>>>>> uses. I didn't check though whether that would properly work here.
>>>>>
>>>>
>>>> OK.
>>>>
>>>>>
>>>>>>>> Same thing we discussed earlier, it's pointless to support this
>>>>>>>> format now. And
>>>>>>> for the form that uses label, maybe we can consider let linker to
>>>>>>> convert 'jmp label''s encoding to jmpabs's. For gas, even if the
>>>>>>> likelihood of a new instruction like 'jmpabs 0x521515' appearing is
>>>>>>> small, that's no reason for us to accept this usage; we think it's
>>>>>>> safer to let
>>>>> the linker support it.
>>>>>>>
>>>>>>> ... how does the linker come into the picture here in the first
>> place?
>>>>>>
>>>>>> We think it's safer to extend the 'jmp label' functionality in the
>>>>>> linker without
>>>>> any conflict with the documentation.
>>>>>
>>>>> That doesn't answer my question. Without that answered I'm also not
>>>>> understanding your reply, I'm afraid.
>>>>>
>>>>
>>>> At first, we worried that the linker wouldn't support "jmpabs label"
>> (This
>>> question may have already been answered). It's the root cause. And then
>> from
>>> my viewpoint, "jmpabs  0x123" isn't allowed, so we consider use another
>>> method to let binutils's user use jmpabs, we think do a optimization in
>> linker
>>> convert jmp to jmpabs is safer.
>>>
>>> Just to mention it: Unless you mean JMPABS -> JMP conversion, the
>> conversion
>>> you mention won't be possible without help by the assembler, as you would
>>> need to reserve more bytes in the section in order to fit the longer
>> insn.
>>> Or maybe you're thinking of inserting "trampoline thunks" (iirc Arm64
>> calls such
>>> "veneers"), themselves required to be within reach of the original JMP?
>>>
>>
>> I didn't consider the code length issue at first. We should have a usage
>> like "mov + jmp", I think we can consider do this conversion "mov + jmp ->
>> jmpabs".
>>
> 
> The reason we didn't add jmpabs to assembler is that
> this instruction isn't designed for compilers nor assembler.
> Its intended usages are for JITs.   Currently
> glibc' ld.so will rewrite PLT entries with jmpabs if enabled
> at runtime.

Well, in e.g. test harnesses one may want to use the insn too. That's
where the complaint was coming from that binutils claim full APX support
but don't implement it (unlike Clang's integrated assembler).

> "jmpabs $foo" should be the only valid syntax.

As before - as long as this remains a subjective opinion without objective
reasons supplied, I can't take this statement as serious.

Jan
  

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

Jan
  

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

Jan
  

On Fri, Oct 11, 2024 at 2:06 PM Jan Beulich <jbeulich@suse.com> 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

$symbol and symbol have different meanings/encodings.

>         jmpabs  $symbol, %rax
>         jmpabs  symbol, %rax
>
> Jan
  

> 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.
  

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

BRs
Lin
  

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.
  

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
  

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, October 11, 2024 5:03 PM
> To: Cui, Lili <lili.cui@intel.com>
> Cc: Hu, Lin1 <lin1.hu@intel.com>; Binutils <binutils@sourceware.org>; H.J. Lu
> <hjl.tools@gmail.com>
> Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in assembler
> 
> 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
> 

0x12345678 is also an offset, relative to the segment base, SDM marks it as moffs, which means " Move doubleword at (seg:offset) to EAX" (the real address is segment base + 0x12345678). 

We also have immediate one.
        
              mov	$0x12345678, %eax
              movabs	$0x12345678, %eax


> there's also nothing RIP-relative. That's what (aiui) the "abs" part of the

It is an offset relative to the segment base, emphasizing that it is an offset, not immediate.

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

jmp	0x12345678
JMP : Jump near, relative, RIP = RIP + 32-bit displacement sign extended to 64-bits.  

jmpabs $0x12345678
JMPABS: The 64-bit immediate operand is treated an as absolute effective address, which is subject to canonicality
checks.

These two formats just reflect the difference between offset and immediate. Why add jmpabs 0x12345678 to confuse the concept?

Thanks,
Lili.

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

On 14.10.2024 05:54, Cui, Lili wrote:
> 
> 
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, October 11, 2024 5:03 PM
>> To: Cui, Lili <lili.cui@intel.com>
>> Cc: Hu, Lin1 <lin1.hu@intel.com>; Binutils <binutils@sourceware.org>; H.J. Lu
>> <hjl.tools@gmail.com>
>> Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in assembler
>>
>> 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
>>
> 
> 0x12345678 is also an offset, relative to the segment base, SDM marks it as moffs, which means " Move doubleword at (seg:offset) to EAX" (the real address is segment base + 0x12345678). 
> 
> We also have immediate one.
>         
>               mov	$0x12345678, %eax
>               movabs	$0x12345678, %eax
> 
> 
>> there's also nothing RIP-relative. That's what (aiui) the "abs" part of the
> 
> It is an offset relative to the segment base, emphasizing that it is an offset, not immediate.

Yet you didn't address my remark regarding you saying "tempRIP = RIP + 0x12345678"
in your earlier reply.

>> 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
>>
> 
> jmp	0x12345678
> JMP : Jump near, relative, RIP = RIP + 32-bit displacement sign extended to 64-bits.  
> 
> jmpabs $0x12345678
> JMPABS: The 64-bit immediate operand is treated an as absolute effective address, which is subject to canonicality
> checks.
> 
> These two formats just reflect the difference between offset and immediate.
> Why add jmpabs 0x12345678 to confuse the concept?

This question was already answered - Because people may look at this differently.
Besides confusion that I saw elsewhere, I can only direct you back to H.J.'s
initial replies, which demonstrated the two way of looking at this pretty well.

And there's nothing "to confuse" here: Following your argumentation further up,
the operand is relative to the CS segment base. That's always zero in 64-bit
mode, but conceptually still exists. The operand also is an address, not a
"plain number".

Jan