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

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

Please remove CpuSSE4_2 from UD0.

-- 
H.J.


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