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: correct UDn


>>> 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.

Jan


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