From: Jan Beulich <jbeulich@suse.com>
To: "Hu, Lin1" <lin1.hu@intel.com>
Cc: "Lu, Hongjiu" <hongjiu.lu@intel.com>,
"binutils@sourceware.org" <binutils@sourceware.org>,
"Cui, Lili" <lili.cui@intel.com>
Subject: Re: [PATCH V5 9/9] Support APX JMPABS for disassembler
Date: Mon, 8 Jan 2024 08:41:18 +0100 [thread overview]
Message-ID: <483e2ffb-fdf0-458b-9900-58c964110a17@suse.com> (raw)
In-Reply-To: <SJ0PR11MB5940D992B0898FC506835C44A66B2@SJ0PR11MB5940.namprd11.prod.outlook.com>
On 08.01.2024 03:32, Hu, Lin1 wrote:
>> -----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.
That's not a general requirement of course, but when it specifically is
work done for you, I would have expected it to be recognized and then
leveraged.
> 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?
Well, no, as long as {rex2} cannot specify any of the payload bits, and when
there are no operands controlling the individual bit (due to there not being
any register/memory operands), it can't be easily expressed using .insn.
Further work would be required to permit that, but for the time being in
_such_ cases it is (of course) okay to use .byte.
Jan
next prev parent reply other threads:[~2024-01-08 7:41 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
2024-01-08 7:41 ` Jan Beulich [this message]
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=483e2ffb-fdf0-458b-9900-58c964110a17@suse.com \
--to=jbeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=hongjiu.lu@intel.com \
--cc=lili.cui@intel.com \
--cc=lin1.hu@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).