Re: [PATCH] x86: correct UDn

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Wed, Nov 22, 2017 at 5:51 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 22.11.17 at 14:34, <hjl.tools@gmail.com> wrote:
>> On Wed, Nov 22, 2017 at 5:13 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 22.11.17 at 13:31, <hjl.tools@gmail.com> wrote:
>>>> On Wed, Nov 22, 2017 at 12:02 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>> On 21.11.17 at 23:12, <hjl.tools@gmail.com> wrote:
>>>>>> On Mon, Nov 20, 2017 at 5:38 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> --- a/opcodes/i386-opc.tbl
>>>>>>> +++ b/opcodes/i386-opc.tbl
>>>>>>> @@ -862,9 +862,12 @@ ud2, 0, 0xf0b, None, 2, Cpu186, No_bSuf|
>>>>>>>  // alias for ud2
>>>>>>>  ud2a, 0, 0xf0b, None, 2, Cpu186,
>>>> No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }
>>>>>>>  // 2nd. official undefined instr.
>>>>>>> -ud1, 0, 0xfb9, None, 2, Cpu186,
>>>> No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }
>>>>>>> +ud1, 2, 0xfb9, None, 2, Cpu186, Modrm|No_bSuf|No_sSuf|No_ldSuf, {
>>>>
>> Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|
>>>> Disp32S, Reg16|Reg32|Reg64 }
>>>>>>>  // alias for ud1
>>>>>>> -ud2b, 0, 0xfb9, None, 2, Cpu186,
>>>> No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }
>>>>>>> +ud2b, 2, 0xfb9, None, 2, Cpu186, Modrm|No_bSuf|No_sSuf|No_ldSuf, {
>>>>
>> Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|
>>>> Disp32S, Reg16|Reg32|Reg64 }
>>>>>>> +// 3rd official undefined instr
>>>>>>> +ud0, 0, 0xfff, None, 2, Cpu186,
>>>>>> No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }
>>>>>>
>>>>>> Do we really need this?  It will confuse disassembler.
>>>>>
>>>>> Well, it's officially documented by both Intel and AMD now. And I
>>>>> don't see why it would confuse the disassembler - neither does
>>>>> that one use the table here, nor is there anything in it (afaik)
>>>>> which would special case opcode 0f ff; are you perhaps mixing
>>>>> this up with opcode ff ff?
>>>>
>>>> Disassembler expects the MODRM byte with 0xffff.  Assembler may
>>>> accept "ud0" without operand.  But it won't be what will be in the output
>>>> from disassembler.
>>>
>>> Well, the disassembler has to pick one form. If the other form was
>>> used as assembler input, things will always look garbled, no matter
>>> what we do.
>>
>> Please remove UD0 without operand.
>
> Well, if you insist.
>
>>>>>>> +ud0, 2, 0xfff, None, 2, CpuSSE4_2, Modrm|No_bSuf|No_sSuf|No_ldSuf, {
>>>>>> Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|
>>>>>> Disp32S, Reg16|Reg32|Reg64 }
>>>>>>
>>>>>> Where does CpuSSE4_2 come from?
>>>>>
>>>>> It's the best I could come up with matching XED specifying this as
>>>>> the variant used from Nehalem onwards.
>>>>>
>>>>
>>>> Can you try it on older machines?
>>>
>>> No, I simply don't have any. But I trust the XED author to have
>>> properly researched it.
>>>
>>
>> I tried this:
>>
>> #include <stdio.h>
>>
>> int
>> main ()
>> {
>>   asm (".byte 0x0f, 0xb");
>>   asm (".byte 0x0f, 0xff, 0xcc");
>>   printf ("hello\n");
>> }
>>
>> on old and new machines.   Both UD2 and UD0 give the same
>>
>> Program received signal SIGILL, Illegal instruction.
>
> Of course. The difference can only be observed when you hand
> the processor a partial instruction, i.e. when crossing a page
> boundary with the ModR/M bytes being right past the page
> boundary: You'll notice #PF on newer processors, but
> supposedly #UD on old ones.
>
>> Please remove CpuSSE4_2 from UD0.
>
> That's implicit if I remove the operand-less form.
>

OK with this change.

Thanks.

-- 
H.J.