This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] x86: correct UDn
>>> 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.
>>>> +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.
Jan