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

["Jan Beulich" <JBeulich at suse dot com>]

>>> On 24.02.17 at 17:15, <hjl.tools@gmail.com> wrote:
> On Fri, Feb 24, 2017 at 12:32 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 23.02.17 at 17:29, <hjl.tools@gmail.com> wrote:
>>> 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?
>>
>> I don't understand the request. vex.w is set correctly (reflecting
>> what the instruction had), but it mustn't be used in certain cases.
>>
>>> 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.
>>
>> Correct. And the disassembler behavior should match that. Hence
>> in 32-/16-bit code VEX-encoded GPR instructions should not
>> disassemble with 64-bit register names, but with 32-bit ones. The
>> main aspect here is that for such instructions VEX.W is not
>> ignored in 64-bit mode, but is ignored in 32-/16-bit mode.
>> However, for VEX-encoded SIMD instructions, VEX.W sensitivity
>> is not bitness dependent. Hence we can't reasonably clear vex.w
>> in the VEX decoding code, as at that point we don't know the
>> main opcode byte yet. The code there, even before this patch,
>> chooses to reflect certain VEX bits into rex, and the patch here
>> simply fills some of the gaps left in that process.
>>
>> May I suggest that you simply look at the testcase included with
>> the patch, and how each sub-block of it disassembles with a
>> non-patches disassembler?
> 
> Please send your patch as attachment since I can't apply it.

Here you go.

Jan

Attachment: binutils-master-ix86-noextreg.patch
Description: Text document