Created attachment 7572 [details] test binary with 26 9B at beginning of text libopcodes decodes the byte sequence 26 9B as the x86 instruction FWAIT of length 1. The 26 is a segment prefix (ES), and the 9B is the FWAIT. I could understand fwait of length 2 if it wanted to include the segment prefix, but as it stands now the disassembly claims that '26' by itself is fwait, which is certainly untrue. $ /usr/local/bin/x86_64-linux-elf-objdump -d -z test.elf test.elf: file format elf32-i386 Disassembly of section .text: 00008000 <.text>: 8000: 26 fwait 8001: 9b fwait ...
Here are some related cases. They may be caused by something slightly different, since FWAIT is so special, but it didn't seem worth filing a new bug. The format is: <hex bytes>: <correct answer> vs <libopcodes output>. I am claiming to know the <correct answer> because libopcodes is choosing to treat the instruction as a single byte. If so, I believe that it should describe the first input byte. 66 67 ad 66 77 88 00 00: data16 vs addr16 66 f0 5f 66 77 88 00 00: data16 vs lock f2 66 67 f0 0f 11 22 00: repnz vs data16 f2 67 ad 66 77 88 00 00: repnz vs addr16 f2 f0 36 66 67 0f 11 22: repnz vs lock f3 66 67 f0 0f 11 22 00: repz vs data16 f3 67 ad 66 77 88 00 00: repz vs addr16 f3 f0 5f 66 77 88 00 00: repz vs lock f3 f2 5f 66 77 88 00 00: repz vs repnz
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, master has been updated via 86a80a50f2cb244e6b9ec18b93675972baa50d78 (commit) from f8c2a73c881913a25c1cb5be766516a75588c7ab (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=86a80a50f2cb244e6b9ec18b93675972baa50d78 commit 86a80a50f2cb244e6b9ec18b93675972baa50d78 Author: H.J. Lu <hjl.tools@gmail.com> Date: Thu May 1 09:39:51 2014 -0700 Handle prefixes before fwait 0x9b (fwait) is both an instruction and an opcode prefix. When 0x9b is treated as an instruction, we need to handle any prefixes before it. This patch handles it properly. gas/testsuite/ PR binutils/16891 * gas/i386/opcode.s: Add test for fwait with prefix. * gas/i386/opcode-intel.d: Updated. * gas/i386/opcode-suffix.d: Likewise. * gas/i386/opcode.d: Likewise. opcodes/ PR binutils/16891 * i386-dis.c (print_insn): Handle prefixes before fwait. ----------------------------------------------------------------------- Summary of changes: gas/testsuite/ChangeLog | 8 ++++++++ gas/testsuite/gas/i386/opcode-intel.d | 2 ++ gas/testsuite/gas/i386/opcode-suffix.d | 2 ++ gas/testsuite/gas/i386/opcode.d | 2 ++ gas/testsuite/gas/i386/opcode.s | 3 +++ opcodes/ChangeLog | 5 +++++ opcodes/i386-dis.c | 8 +++++++- 7 files changed, 29 insertions(+), 1 deletions(-)
(In reply to Russ Cox from comment #1) > Here are some related cases. They may be caused by something slightly > different, since FWAIT is so special, but it didn't seem worth filing a new > bug. Fixed in 2.25. > The format is: <hex bytes>: <correct answer> vs <libopcodes output>. I am > claiming to know the <correct answer> because libopcodes is choosing to > treat the instruction as a single byte. If so, I believe that it should > describe the first input byte. > > 66 67 ad 66 77 88 00 00: data16 vs addr16 > 66 f0 5f 66 77 88 00 00: data16 vs lock > f2 66 67 f0 0f 11 22 00: repnz vs data16 > f2 67 ad 66 77 88 00 00: repnz vs addr16 > f2 f0 36 66 67 0f 11 22: repnz vs lock > f3 66 67 f0 0f 11 22 00: repz vs data16 > f3 67 ad 66 77 88 00 00: repz vs addr16 > f3 f0 5f 66 77 88 00 00: repz vs lock > f3 f2 5f 66 77 88 00 00: repz vs repnz Please open a new bug report for each different case and be specific. For example, with 66 67 ad 66 77 88 00 00, I got 0: 66 67 ad lods %ds:(%si),%ax 3: 66 data16 4: 77 88 ja 0xffffff8e Which data16 are you referring to?
Thanks for the FWAIT fix. I'll file a separate report with more details, as you suggest.