From: "H.J. Lu" <hjl.tools@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Jiang, Haochen" <haochen.jiang@intel.com>,
Binutils <binutils@sourceware.org>
Subject: Re: [PATCH 2/2] x86: adjust disassembly of insns operating on selector values
Date: Thu, 20 Jul 2023 18:20:24 -0700 [thread overview]
Message-ID: <CAMe9rOpTOZOd5vLzf+bQScG4pJ=xcBiA2y9YMmjnHarwPuwrHA@mail.gmail.com> (raw)
In-Reply-To: <6e5ddbfd-4060-edff-39ba-f3446b210eb5@suse.com>
On Mon, Jul 17, 2023 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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
Personally, I don't think this change is necessary. But I am not
against it.
--
H.J.
prev parent reply other threads:[~2023-07-21 1:21 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
2023-07-21 1:20 ` H.J. Lu [this message]
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='CAMe9rOpTOZOd5vLzf+bQScG4pJ=xcBiA2y9YMmjnHarwPuwrHA@mail.gmail.com' \
--to=hjl.tools@gmail.com \
--cc=binutils@sourceware.org \
--cc=haochen.jiang@intel.com \
--cc=jbeulich@suse.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).