This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] x86: ignore high register select bit(s) in 32- and 16-bit modes


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]