From: Jan Beulich <jbeulich@suse.com>
To: "Jiang, Haochen" <haochen.jiang@intel.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>, Binutils <binutils@sourceware.org>
Subject: Re: [PATCH 2/2] x86: adjust disassembly of insns operating on selector values
Date: Mon, 17 Jul 2023 09:08:52 +0200 [thread overview]
Message-ID: <6e5ddbfd-4060-edff-39ba-f3446b210eb5@suse.com> (raw)
In-Reply-To: <SA1PR11MB594681AAD11A319BE1B67C65EC3BA@SA1PR11MB5946.namprd11.prod.outlook.com>
On 17.07.2023 04:04, Jiang, Haochen wrote:
>> --- a/gas/testsuite/gas/i386/opcode-suffix.d
>> +++ b/gas/testsuite/gas/i386/opcode-suffix.d
>> @@ -102,7 +102,7 @@ Disassembly of section .text:
>> *[0-9a-f]+: 60[ ]+pushal
>> *[0-9a-f]+: 61[ ]+popal
>> *[0-9a-f]+: 62 90 90 90 90 90[ ]+boundl %edx,-0x6f6f6f70\(%eax\)
>> - *[0-9a-f]+: 63 90 90 90 90 90[ ]+arpl[ ]+%dx,-0x6f6f6f70\(%eax\)
>> + *[0-9a-f]+: 63 90 90 90 90 90[ ]+arpll[ ]+%edx,-
>> 0x6f6f6f70\(%eax\)
>> *[0-9a-f]+: 68 90 90 90 90[ ]+pushl[ ]+\$0x90909090
>> *[0-9a-f]+: 69 90 90 90 90 90 90 90 90 90[ ]+imull[
>> ]+\$0x90909090,-0x6f6f6f70\(%eax\),%edx
>> *[0-9a-f]+: 6a 90[ ]+pushl[ ]+\$0xffffff90
>> @@ -248,7 +248,7 @@ Disassembly of section .text:
>> *[0-9a-f]+: fc[ ]+cld
>> *[0-9a-f]+: fd[ ]+std
>> *[0-9a-f]+: ff 90 90 90 90 90[ ]+calll[ ]+\*-0x6f6f6f70\(%eax\)
>> - *[0-9a-f]+: 0f 00 90 90 90 90 90[ ]+lldt[ ]+-0x6f6f6f70\(%eax\)
>> + *[0-9a-f]+: 0f 00 90 90 90 90 90[ ]+lldtw[ ]+-0x6f6f6f70\(%eax\)
>
> H.J. is on vacation till Wednesday but I suppose H.J. has this question in my patch
> before and he might raise again if he is here.
>
> Is this suffix needed since m16 is the only allowed memory here?
All suffixes should be appended in suffix-always mode. The question
of whether one can be omitted arises only in the default mode, where
optional suffixes are left off (for clarity / ease of reading). Plus
please recall that the changes here are for consistency, and e.g. in
*[0-9a-f]+: 8c 90 90 90 90 90[ ]+movw[ ]+%ss,-0x6f6f6f70\(%eax\)
the suffix is also present, no matter that only m16 is possible.
In any event I'm not intending to commit this before the end of the
week, so H.J. will have a chance to voice his opinion.
Jan
next prev parent reply other threads:[~2023-07-17 7:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-14 10:01 [PATCH 0/2] x86: adjust disassembling of selector-access insns Jan Beulich
2023-07-14 10:02 ` [PATCH 1/2] x86: simplify disassembly of LAR/LSL Jan Beulich
2023-07-14 10:02 ` [PATCH 2/2] x86: adjust disassembly of insns operating on selector values Jan Beulich
2023-07-17 2:04 ` Jiang, Haochen
2023-07-17 7:08 ` Jan Beulich [this message]
2023-07-21 1:20 ` H.J. Lu
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=6e5ddbfd-4060-edff-39ba-f3446b210eb5@suse.com \
--to=jbeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=haochen.jiang@intel.com \
--cc=hjl.tools@gmail.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).