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

H.J. Lu hjl.tools@gmail.com
Thu Feb 23 16:29:00 GMT 2017


On Thu, Feb 23, 2017 at 8:16 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 23.02.17 at 16:54, <hjl.tools@gmail.com> wrote:
>> 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:
>>>>> @@ -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.
>
> That's because for 64-bit code REX_W gets ser from vex.w
> during VEX decoding. For 16- and 32-bit code this doesn't happen,
> and hence looking at vex.w (possibly set) is wrong here, while

vex.w must be set correctly.  Can you show me where it is set
incorrectly?

For GPR instructions with VEX/EVEX encoding in 16/32 bit mode,
if vex.w is ignored, it shouldn't matter.  If it isn't ignored, it should UD.

> rex & REX_W (always clear for these modes) gives the correct
> result.
>
> Jan
>



-- 
H.J.



More information about the Binutils mailing list