Feature #1096

i386 disassembler should understand complex nops

Added by Rich Lowe almost 10 years ago. Updated over 9 years ago.

lib - userland libraries
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


I have some code which contains some of the weirder amd64 nop instructions (specifically, nopl, a nop with an argument). libdisasm appears to have no knowledge of this, mdb spits out:
ERROR--unknown op code

dis trips on it completely, and fails to disassemble from that point onward.


Updated by Rich Lowe almost 10 years ago

Intel call this "hinting nops"

The documented ones are dealt with pretty reasonably by:

@@ -1443,7 +1443,7 @@
 /*  [10]  */    TNSZ("movups",XMMO,16),    TNSZ("movups",XMMOS,16),TNSZ("movlps",XMMO,8),    TNSZ("movlps",XMMOS,8),
 /*  [14]  */    TNSZ("unpcklps",XMMO,16),TNSZ("unpckhps",XMMO,16),TNSZ("movhps",XMMOM,8),TNSZ("movhps",XMMOMS,8),
 /*  [18]  */    IND(dis_op0F18),    INVALID,        INVALID,        INVALID,
-/*  [1C]  */    INVALID,        INVALID,        INVALID,        TS("nop", M),
+/*  [1C]  */    INVALID,        INVALID,        INVALID,        INVALID,
 }, {
 /*  [20]  */    TSy("mov",SREG),    TSy("mov",SREG),    TSy("mov",SREG),    TSy("mov",SREG),
 /*  [24]  */    TSx("mov",SREG),    INVALID,        TSx("mov",SREG),    INVALID,

Which handles 0f 1f (nopl), 66 0f 1f (nopw). but not 66 2e 0f 1f (nopw %cs:).
This catches many of the new nops I've found in actual code, and would catch all (or nearly so) if it handled the %cs: variant.

Apparently the full range from 0f 18 to 0f 1f are reserved and used, at least by Intel, as "Hinting nops". Possibly we should just decode the full set as some obviously generatable string?


Updated by Rich Lowe almost 10 years ago

  • Assignee set to Rich Lowe
  • % Done changed from 0 to 60

Actually, these are just regular multibyte nops, not the "hinting nops" to which intel refer (which are, as stated, the reserved opcodes in a given range).

I have tentative changes for this on my GCC branch.


Updated by Rich Lowe over 9 years ago

  • Status changed from New to Resolved
  • % Done changed from 60 to 100

Resolved in r13442 commit:4adbe6de60c8

With a combination of changes from Bryan Cantrill at Joyent, and my GCC branch.

Also available in: Atom PDF