From: "Hu, Lin1" <lin1.hu@intel.com>
To: "Beulich, Jan" <JBeulich@suse.com>, "Cui, Lili" <lili.cui@intel.com>
Cc: "Lu, Hongjiu" <hongjiu.lu@intel.com>,
"binutils@sourceware.org" <binutils@sourceware.org>
Subject: RE: [PATCH V5 9/9] Support APX JMPABS for disassembler
Date: Mon, 8 Jan 2024 02:32:50 +0000 [thread overview]
Message-ID: <SJ0PR11MB5940D992B0898FC506835C44A66B2@SJ0PR11MB5940.namprd11.prod.outlook.com> (raw)
In-Reply-To: <f1d6940e-aa3f-451a-99f6-f6ef854efb4b@suse.com>
> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, January 5, 2024 8:09 PM
> To: Cui, Lili <lili.cui@intel.com>
> Cc: Lu, Hongjiu <hongjiu.lu@intel.com>; Hu, Lin1 <lin1.hu@intel.com>;
> binutils@sourceware.org
> Subject: Re: [PATCH V5 9/9] Support APX JMPABS for disassembler
>
> On 28.12.2023 02:27, Cui, Lili wrote:
> > --- /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
> > +# With 67 prefix
> > + .byte 0x67,0xd5,0x00,0xa1,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> > +# With F2 prefix
> > + .byte 0xf2,0xd5,0x00,0xa1,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> > +# With F3 prefix
> > + .byte 0xf3,0xd5,0x00,0xa1,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> > +# With LOCK prefix
> > + .byte 0xf0,0xd5,0x00,0xa1,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> > +# REX2.M0 = 0 REX2.W = 1
> > + .byte 0xd5,0x08,0xa1,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00
>
> Considering that I specifically asked that this use .insn, and that I further took
> the time to make a patch to make .insn work with {rex2}, I find it rather poor
> that here and ...
>
> > --- /dev/null
> > +++ b/gas/testsuite/gas/i386/x86-64-apx-jmpabs.s
> > @@ -0,0 +1,5 @@
> > +# Check 64bit APX_F JMPABS instructions
> > +
> > + .text
> > + _start:
> > + .byte 0xd5,0x00,0xa1,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x00
>
> ... here it is still .byte that is being used.
>
I'm not always keeping my eye on what patches push in Binutils. We can upstream a new fix patch like this.
.text
# With 66 prefix
- .byte 0x66,0xd5,0x00,0xa1,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00
+ .insn {rex2} data16 0xa1, $1{:u64}
# With 67 prefix
- .byte 0x67,0xd5,0x00,0xa1,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00
+ .insn {rex2} addr32 0xa1, $1{:u64}
# With F2 prefix
- .byte 0xf2,0xd5,0x00,0xa1,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00
+ .insn {rex2} repne 0xa1, $1{:u64}
# With F3 prefix
- .byte 0xf3,0xd5,0x00,0xa1,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00
+ .insn {rex2} rep 0xa1, $1{:u64}
# With LOCK prefix
- .byte 0xf0,0xd5,0x00,0xa1,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00
+ .insn {rex2} lock 0xa1, $1{:u64}
# REX2.M0 = 0 REX2.W = 1
- .byte 0xd5,0x08,0xa1,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00
+ .insn {rex2} 0x08,0xa1, $1{:u64}
+#.byte 0xd5,0x08,0xa1,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00
But the last test " REX2.M0 = 0 REX2.W = 1" is invalid, do you have some advise?
BRs,
Lin
next prev parent reply other threads:[~2024-01-08 2:32 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-28 1:27 [PATCH V5 0/9] Support Intel APX EGPR Cui, Lili
2023-12-28 1:27 ` [PATCH V5 1/9] Support APX GPR32 with rex2 prefix Cui, Lili
2023-12-28 1:53 ` H.J. Lu
2024-01-04 8:02 ` Jan Beulich
2024-01-04 11:27 ` Cui, Lili
2024-01-05 14:45 ` Jan Beulich
2024-01-08 3:41 ` Cui, Lili
2023-12-28 1:27 ` [PATCH V5 2/9] Created an empty EVEX_MAP4_ sub-table for EVEX instructions Cui, Lili
2023-12-28 1:54 ` H.J. Lu
2023-12-28 1:27 ` [PATCH V5 3/9] Support APX GPR32 with extend evex prefix Cui, Lili
2023-12-28 1:54 ` H.J. Lu
2023-12-28 13:48 ` Cui, Lili
2023-12-28 1:27 ` [PATCH V5 4/9] Add tests for " Cui, Lili
2023-12-28 1:54 ` H.J. Lu
2023-12-28 1:27 ` [PATCH V5 5/9] Support APX NDD Cui, Lili
2023-12-28 1:55 ` H.J. Lu
2023-12-28 1:27 ` [PATCH V5 6/9] Support APX Push2/Pop2 Cui, Lili
2023-12-28 1:55 ` H.J. Lu
2023-12-28 1:27 ` [PATCH V5 7/9] Support APX pushp/popp Cui, Lili
2023-12-28 1:56 ` H.J. Lu
2023-12-28 1:27 ` [PATCH V5 8/9] Support APX NDD optimized encoding Cui, Lili
2023-12-28 1:56 ` H.J. Lu
2024-01-05 14:36 ` Jan Beulich
2024-01-08 2:49 ` Hu, Lin1
2023-12-28 1:27 ` [PATCH V5 9/9] Support APX JMPABS for disassembler Cui, Lili
2023-12-28 1:56 ` H.J. Lu
2024-01-05 12:08 ` Jan Beulich
2024-01-08 2:32 ` Hu, Lin1 [this message]
2024-01-08 7:41 ` Jan Beulich
2024-01-08 7:44 ` Hu, Lin1
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR11MB5940D992B0898FC506835C44A66B2@SJ0PR11MB5940.namprd11.prod.outlook.com \
--to=lin1.hu@intel.com \
--cc=JBeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=hongjiu.lu@intel.com \
--cc=lili.cui@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).