Possible XED Decode Bug (from Pin rev 65163)

[Paul_J_]

I may have spotted a bug in XED when decoding 64-bit instructions while unit testing my own disassembler.

To recreate: 
I have setup the decoder to use XED_MACHINE_MODE_LONG_64 with XED_ADDRESS_WIDTH_64b. The problem appears to be that XED will more than one REX prefix and generate an instruction. For example:
 
41-40-26-E8-77-70-C5-A2
call 0xffffffffa2dc607f
 
The E8 is the call instruction op code, with a 41-40-26 prefix (hex). 41 and 40 are obviously both REX prefixes.
 
According to section Volume 2, 2.2.1 (REX prefixes) of the Intel 64 and IA-32 Architectures (June 2013 - Combined) "Only one REX prefix is allowed per instruction".
 
Is this a fault of XED or am I misunderstanding. Apologies if so!
 
I was using the XED decoder which came with the latest revision of Pin, r65136.
 
If this is of use then I've noticed faults in XED previously which were fixed in later versions - is it useful to keep reporting them via this mechanism or is another way better? (the email provided in XED doesn't work - sde-dev@intel.com)

Thanks for your time.

[MarkC_Intel]

Hi, Not sure I understand what you are doing yet.  Feel free to elaborate. The xed decoder does not generate instructions. Where does this instruction with redundant rex prefixes come from? Are you sure it is 64b code? There are rules for handling instructions with multiple rex prefixes.  AFAIK, the XED encoder is not capable of generating more than one rex prefix so I'm guessing this instruction came from somewhere else.  Please let me know. Thanks.

> The problem appears to be that XED will more than one REX prefix and generate an instruction.

Seems like there is a word missing after "will" in the above sentence.

> 41-40-26-E8-77-70-C5-A2

According to the rules for handling repeated rex prefixes, only the last rex prefix (just before the opcode) is respected.  (See SDM, rev 51, volume 2, section 2.2.1).  So in this case the initial 41 and the 40 are  ignored because there is a  0x26 prefix before the opcode.

If you download the latest SDE kit you'll get a xed command line tool binary you can use to explore instructions.

http://www.intel.com/software/sde

For this one:

.% /xed -64 -d 41 40 26 e8 77 70 c5 a2
414026E87770C5A2
ICLASS: CALL_NEAR   CATEGORY: CALL   EXTENSION: BASE  IFORM: CALL_NEAR_RELBRd   ISA_SET: I86
SHORT: call 0xffffffffa2c5707f

The sde-dev@intel.com is an internal mailing list for Intel SDE. For XED, you can post questions here or contact me directly,  mark dot charney (at intel dot com).

Thank you for your interest. Regards, Mark

[Paul_J_]

Thanks for the prompt reply and sorry for the badly worded/confusing post!

To clarify what I have been doing...

I have been using the XED engine (pin/extras/xed2-intel64/lib/libxed.lid) as a "known good" engine to test my code against (nothing commercial, just personal development/interest). So I've been generating byte sequences, feeding them into the xed_decode, and then using xed_format to produce Intel formatted string which so I can compare my output against it. I'm attempting to generate byte sequences that cover all the instructions and a good coverage of prefixes, etc (~14 million different sequences for x64). This is why the byte sequence looks odd, it wasn't generated by an assembler, just some raw data generation that I have produced.

Also, thank you for correcting my understanding on prefixes, it has been very useful. I have downloaded the latest SDM and I'll give Volume 2, Chapter 2 a detailed read (!) and I've just got the latest copy of the SDE so I'll use the command line engine to explore instructions more.

As an aside, thanks for your time/effort on tools and products such as SDE/Pin/XED!