This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] x86: ignore high register select bit(s) in 32- and 16-bit modes
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jan Beulich <JBeulich at suse dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Thu, 23 Feb 2017 07:54:17 -0800
- Subject: Re: [PATCH] x86: ignore high register select bit(s) in 32- and 16-bit modes
- Authentication-results: sourceware.org; auth=none
- References: <58AC7878020000780013C5AD@prv-mh.provo.novell.com> <CAMe9rOr5OyeQ35ss_Y73dz5yfLGxCKuZt=jPf8fSAxyfrdE=0Q@mail.gmail.com> <58AE9F8F020000780013D0AF@prv-mh.provo.novell.com>
On Wed, Feb 22, 2017 at 11:38 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 22.02.17 at 20:03, <hjl.tools@gmail.com> wrote:
>> On Tue, Feb 21, 2017 at 8:27 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> While commits 9889cbb14e ("Check invalid mask registers") and
>>> abfcb414b9 ("X86: Ignore REX_B bit for 32-bit XOP instructions") went a
>>> bit into the right direction, this wasn't quite enough:
>>> - VEX.vvvv has its high bit ignored
>>> - EVEX.vvvv has its high bit ignored together with EVEX.v'
>>> - the high bits of {,E}VEX.vvvv should not be prematurely zapped, to
>>> allow proper checking of them when the fields has to hold al ones
>>> - when the high bits of an immediate specify a register, bit 7 is
>>> ignored
>>> - GPR names should be determined base on REX_W rather than vex.w
>>>
>>> gas/
>>> 2017-02-21 Jan Beulich <jbeulich@suse.com>
>>>
>>> * gas/testsuite/gas/i386/noextreg.s,
>>> gas/testsuite/gas/i386/noextreg.d: New.
>>> * testsuite/gas/i386/i386.exp: Run new test.
>>>
>>> opcodes/
>>> 2017-02-21 Jan Beulich <jbeulich@suse.com>
>>>
>>> * i386-dis.c (VEXI4_Fixup, VexI4): Delete.
>>> (prefix_table): Remove uses of VexI4.
>>> (get_valid_dis386): Never flag bad opcode when
>>> vex.register_specifier is beyond 7. Always store all four
>>> bits of it. Move 16-/32-bit override in EVEX handling after
>>> all to be overridden bits have been set.
>>> (OP_VEX): Mask vex.register_specifier outside of 64-bit mode.
>>> Use rex to determine GPR register set.
>>> (OP_EX_VexReg, OP_Vex_2src_1, OP_Vex_2src_2): Mask
>>> vex.register_specifier outside of 64-bit mode.
>>> (OP_EX_VexW): Advance codep when 2nd pass done, deferring the
>>> setting of vex_w_done until after that.
>>> (OP_REG_VexI4): Don't check low four immediate bits. Mask
>>> vex.register_specifier outside of 64-bit mode.
>>> (OP_LWPCB_E): Use rex to determine GPR register set.
>>> (OP_LWP_E): Likewise. Mask vex.register_specifier outside of
>>> 64-bit mode.
>>>
>>
>>> @@ -16937,7 +16928,7 @@ OP_VEX (int bytemode, int sizeflag ATTRI
>>> names = names_xmm;
>>> break;
>>> case dq_mode:
>>> - if (vex.w)
>>> + if (rex & REX_W)
>>> names = names64;
>>> else
>>> names = names32;
>>
>> Do you have a testcase where vex.w != rex & REX_W?
>
> I'm sorry, but I don't think I understand the question in the light
> of there being a testcase added covering all of the previous
> misbehaviors I'm aware of.
My question is why vex.w and rex & REX_W are out of sync
at this point.
--
H.J.