I encountered a strange x86-32 instruction (opcode
0x65) decoded by
gs). I found it while a full linear sweep of a binary (
objdump -D), so the decoding was surely incorrect. But, still,
objdump didn't decode it as a
(bad) instruction, so it means that it can be encountered and I would like to know what does it means.
Here is an example of this instruction:
080484fc <_IO_stdin_used>: 80484fc: 01 00 add %eax,(%eax) 80484fe: 02 00 add (%eax),%al 8048500: 48 dec %eax 8048501: 65 gs <======================= Here!!! 8048502: 6c insb (%dx),%es:(%edi) 8048503: 6c insb (%dx),%es:(%edi) 8048504: 6f outsl %ds:(%esi),(%dx) 8048505: 20 57 6f and %dl,0x6f(%edi) 8048508: 72 6c jb 8048576 <_IO_stdin_used+0x7a> 804850a: 64 21 0a and %ecx,%fs:(%edx) 804850d: 00 44 6f 64 add %al,0x64(%edi,%ebp,2) 8048511: 67 65 20 54 68 and %dl,%gs:0x68(%si) 8048516: 69 .byte 0x69 8048517: 73 21 jae 804853a <_IO_stdin_used+0x3e>
Note that searching for this instruction on the Web is quite difficult because of the
%gs register which mask all other possible hit.
So, is it a real "instruction" or is it glitch produced by
0x65correspond in fact to a prefix corresponding to
%gs:(mem_ref). But, here, the
libopcodesparser seems to wrongly interpret it and forget to interpret what follow as a memory reference... (I may be wrong, but I will try to answer when I will know more about all this).
ins*instructions ignore segment override prefixes and always use
0x65followed by an
insinstruction that the decoder is wrong... I see, it is interesting. Thanks.