[PATCH v4 9/9] Support APX JMPABS for disassembler
Hu, Lin1
lin1.hu@intel.com
Tue Dec 12 07:10:59 GMT 2023
> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Monday, December 11, 2023 9:04 PM
> To: Cui, Lili <lili.cui@intel.com>; Hu, Lin1 <lin1.hu@intel.com>
> Cc: binutils@sourceware.org; Lu, Hongjiu <hongjiu.lu@intel.com>
> Subject: Re: [PATCH v4 9/9] Support APX JMPABS for disassembler
>
> On 07.12.2023 10:01, Cui, Lili wrote:
> > --- /dev/null
> > +++ b/gas/testsuite/gas/i386/x86-64-apx-jmpabs-intel.d
> > @@ -0,0 +1,11 @@
> > +#as:
> > +#objdump: -dw -Mintel
> > +#name: x86_64 APX_F JMPABS insns (Intel disassembly)
> > +#source: x86-64-apx-jmpabs.s
> > +
> > +.*: +file format .*
> > +
> > +Disassembly of section \.text:
> > +
> > +0+ <_start>:
> > +\s*[a-f0-9]+:\s*d5 00 a1 02 00 00 00 00 00 00 00[ ]+jmpabs 0x2
>
> Missing #pass ?
>
Have added #pass in all tests.
>
> > --- /dev/null
> > +++ b/gas/testsuite/gas/i386/x86-64-apx-jmpabs-inval.d
> > @@ -0,0 +1,40 @@
> > +#as: --64
> > +#objdump: -dw
> > +#name: illegal decoding of APX_F jmpabs insns
> > +#source: x86-64-apx-jmpabs-inval.s
> > +
> > +.*: +file format .*
> > +
> > +Disassembly of section \.text:
> > +
> > +0+ <.text>:
> > +\s*[a-f0-9]+: 66 d5 00 a1[ ]+\(bad\)
> > +\s*[a-f0-9]+: 01 00[ ]+add %eax,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: 67 d5 00 a1[ ]+\(bad\)
> > +\s*[a-f0-9]+: 01 00[ ]+add %eax,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: f2 d5 00 a1[ ]+\(bad\)
> > +\s*[a-f0-9]+: 01 00[ ]+add %eax,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: f3 d5 00 a1[ ]+\(bad\)
> > +\s*[a-f0-9]+: 01 00[ ]+add %eax,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: f0 d5 00 a1[ ]+\(bad\)
> > +\s*[a-f0-9]+: 01 00[ ]+add %eax,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: d5 08 a1[ ]+\(bad\)
> > +\s*[a-f0-9]+: 01 00[ ]+add %eax,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*[a-f0-9]+: 00 00[ ]+add %al,\(%rax\)
> > +\s*...
>
> The more "canonical" way of expressing this is #pass.
>
> > --- /dev/null
> > +++ b/gas/testsuite/gas/i386/x86-64-apx-jmpabs-inval.s
> > @@ -0,0 +1,15 @@
> > +# Check bytecode of APX_F jmpabs instructions with illegal encode.
> > +
> > + .text
> > +# With 66 prefix
> > + .byte 0x66,0xd5,0x00,0xa1,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00
>
> At the example of this, can't this be
>
> .insn {rex2} data16 0xa1, $1{:u64}
>
Unfortunately, It's useless, it raised
Error: bad or irreducible absolute expression.
Error: junk at end of line, first unrecognized character is `d'
>
> I notice though that
>
> .insn {rex} 0xa1, $1{:u64}
>
> presently ignores {rex}, which looks like a bug I ought to fix.
>
Indeed, When I change the line like .insn data16 {rex2} 0xa1, $1{:u64}. {rex2} will be ignored too.
>
> .insn rex 0xa1, $1{:u64}
>
> does work though (and so should {rex2}).
>
rex2 raised the same error.
Error: bad or irreducible absolute expression.
Error: junk at end of line, first unrecognized character is `d'
>
> > @@ -9777,7 +9778,7 @@ print_insn (bfd_vma pc, disassemble_info *info, int
> intel_syntax)
> > ins.all_prefixes[ins.last_rex_prefix] = 0;
> >
> > /* Check if the REX2 prefix is used. */
> > - if (ins.last_rex2_prefix >= 0 && (ins.rex2 & 7))
> > + if (ins.last_rex2_prefix >= 0 && (ins.rex2 & (7 | REX2_SPECIAL)))
> > ins.all_prefixes[ins.last_rex2_prefix] = 0;
>
> Seeing that REX2_SPECIAL isn't introduced here, doesn't this belong in the
> PUSHP/POPP patch then?
>
Indeed, I have tell lili.
>
> > @@ -13933,3 +13934,37 @@ PUSH2_POP2_Fixup (instr_info *ins, int
> > bytemode, int sizeflag)
> >
> > return OP_VEX (ins, bytemode, sizeflag); }
> > +
> > +static bool
> > +JMPABS_Fixup (instr_info *ins, int bytemode, int sizeflag) {
> > + if (ins->address_mode == mode_64bit
>
> I think I had asked before already: Is this really needed when ...
>
> > + && ins->last_rex2_prefix >= 0
>
> ... this can be non-negative only in 64-bit mode anyway?
>
I've tried it and it doesn't seem to be needed, it (ins->address_mode == mode_64bit) has been removed.
>
> > + && (ins->rex2 & 0x80) == 0x0)
>
> What is 0x80? DYM the respective equivalent #define for the opcode map bit
> (which ought to be 0x8 aiui)?
>
0x80 is corresponding to rex2.M0. 0x8 is corresponding to rex2.W.
>
> Further on what basis was the split determined between the conditions here
> and ...
>
>
> > + {
> > + uint64_t op;
> > +
> > + if (bytemode == eAX_reg)
> > + return true;
> > +
> > + if (!get64 (ins, &op))
> > + return false;
> > +
> > + if ((ins->prefixes & (PREFIX_OPCODE | PREFIX_ADDR | PREFIX_LOCK)) !=
> 0x0
> > + || (ins->rex & REX_W) != 0x0)
>
> ... these further ones?
>
It does look like they could be put together, I've adjusted the part of code.
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index fa242c4dff5..5c32b7b7f0e 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -13938,25 +13938,24 @@ PUSH2_POP2_Fixup (instr_info *ins, int bytemode, int sizeflag)
static bool
JMPABS_Fixup (instr_info *ins, int bytemode, int sizeflag)
{
- if (ins->address_mode == mode_64bit
- && ins->last_rex2_prefix >= 0
- && (ins->rex2 & 0x80) == 0x0)
+ if (ins->last_rex2_prefix >= 0)
{
uint64_t op;
- if (bytemode == eAX_reg)
- return true;
-
- if (!get64 (ins, &op))
- return false;
-
if ((ins->prefixes & (PREFIX_OPCODE | PREFIX_ADDR | PREFIX_LOCK)) != 0x0
- || (ins->rex & REX_W) != 0x0)
+ || (ins->rex & REX_W) != 0x0
+ || (ins->rex2 & 0x80) != 0x0)
{
oappend (ins, "(bad)");
return true;
}
+ if (bytemode == eAX_reg)
+ return true;
+
+ if (!get64 (ins, &op))
+ return false;
+
ins->mnemonicendp = stpcpy (ins->obuf, "jmpabs");
ins->rex2 |= REX2_SPECIAL;
oappend_immediate (ins, op);
>
> Overall it's a bit sad of course to have only the disassembler side of this, but
> well ...
>
The assembler side may be supported until glibc can support jmpabs label.
BRs,
Lin
More information about the Binutils
mailing list