perror
2013-08-23 20:01:18 UTC
我遇到了一個奇怪的x86-32指令（操作碼 0x65 ），由 objdump 解碼為 gs （不是％gs 代碼>，但 gs ）。我在對二進製文件（ objdump -D ）進行完全線性掃描時發現了它，因此解碼肯定不正確。但是， objdump 仍未將其解碼為（錯誤）指令，因此這意味著可以遇到它，我想知道它的含義。
這是此指令的示例：
080484fc <_IO_stdin_used>：80484fc：01 00 add％eax，（％eax）80484fe：02 00 add（％eax）， ％al 8048500：12月48日％eax 8048501：65 gs < =======================這裡！！！ 8048502：6c insb（％dx），％es：（％edi）8048503：6c insb（％dx），％es：（％edi）8048504：6f outsl％ds：（％esi），（％dx）8048505： 20 57 6f和％dl，0x6f（％edi）8048508：72 6c jb 8048576 <_IO_stdin_used + 0x7a> 804850a：64 21 0a和％ecx，％fs：（％edx）804850d：00 44 6f 64添加％al，0x64（ edi，％ebp，2）8048511：67 65 20 54 68和％dl，％gs：0x68（％si）8048516：69 .byte 0x69 8048517：73 21 jae 804853a <_IO_stdin_used + 0x3e> 請注意，由於％gs 寄存器會掩蓋所有其他可能的結果，因此在Web上搜索該指令非常困難。
那麼，這是真正的“指令”嗎？還是由 gas 產生的故障？
嗯，這似乎是來自GNU binutils的錯誤……操作碼0x65實際上對應於與％gs：（mem_ref）相對應的前綴。但是，在這裡，`libopcodes`解析器似乎錯誤地解釋了它，而* forget *則將後面的解釋解釋為內存引用...（我可能是錯的，但是當我對所有這些都了解更多時，我會盡力回答） 。
根據Intel的手冊，`ins *`指令* ignore *段會覆蓋前綴，並始終使用％es。
因此，這意味著這是因為您在操作碼0x65後面加上了一個ins指令，表明解碼器是錯誤的……我知道，這很有趣。謝謝。
有點晚了，但是：解碼器將它弄錯了，因為您正在反彙編以零結尾的*文本字符串*。當輸入錯誤的輸入時，您不能對“好”或“壞”的拆卸做出決定。 （有趣：這個字符串非常有名，以至於我在對前三個字符進行解碼後才得到它。）