This is the mail archive of the 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 Fri, Feb 24, 2017 at 12:32 AM, Jan Beulich <> wrote:
>>>> On 23.02.17 at 17:29, <> wrote:
>> On Thu, Feb 23, 2017 at 8:16 AM, Jan Beulich <> wrote:
>>>>>> On 23.02.17 at 16:54, <> wrote:
>>>> On Wed, Feb 22, 2017 at 11:38 PM, Jan Beulich <> wrote:
>>>>>>>> On 22.02.17 at 20:03, <> wrote:
>>>>>> On Tue, Feb 21, 2017 at 8:27 AM, Jan Beulich <> 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?
> Jan

Please send your patch as attachment since I can't apply it.


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