Instruction 0x8f (pop) is valid only when the reg field is zero - it's really an
instruction group that has only one instruction in it. Attempting to execute
this instruction with anything else in that field generates an invalid opcode
exception on all the CPUs I have around here. Objdump ignores the contents of
this field, and decodes any 0x8f opcode as a pop. For example, this invalid
code:
.text
.byte 0x8f, 0x62, 0x90
Will decode as:
804832d: 8f 62 90 popl 0xffffff90(%edx)
(The correct encoding for this popl instruction would be 0x8f 0x42 0x90)
It really should be rejected as an invalid instruction. I stumbled across this
while trying to debug a mystifying SIGILL, and it took a while to realise that
objdump's disassembly was just wrong and there was a bit error in the
instruction.
There's a couple of other instructions which are encoded in this fashion. I
haven't checked these, but the same issue probably applies to them too:
0xc6 mov
0x0f90 set{cc}
--
Summary: Bogus decoding of certain invalid i386 instructions
(0x8f pop)
Product: binutils
Version: 2.17
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: asuffield at suffields dot me dot uk
CC: bug-binutils at gnu dot org
GCC target triplet: i386-*
http://sourceware.org/bugzilla/show_bug.cgi?id=4333
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
