-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[x86 disassembler] crc32 not disassembled correctly #11074
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
assigned to @topperc |
Fixed this in r138771. |
Reopening because the following case doesn't work echo '0x66 0xf2 0x0f 0x38 0xf1 0xc0'| ./llvm-mc -disassemble -triple="x86_64" Should be "crc32w %ax, %eax" The disassembler doesn't really know what to do with 0x66 and 0xf2 on the same instruction and fails to match the opcode correctly. The destination operand needs to ignore the 0x66 prefix. Also this should decode to MOVBE which I don't think is supported at all in LLVM. echo '0x0f 0x38 0xf1 0xc0'| ./llvm-mc -disassemble -triple="x86_64 |
I filed bug 10832 to track the movbe bug. |
Fix the disassembly of the X86 "crc32w %ax, %eax" instruction in r139014. |
But now this doesn't decode correctly 0xf2 0x0f 0x38 0xf1 0xc0 |
Fixed in r140954. |
Testing with r140997: $ echo '0xf2 0x0f 0x38 0xf0 0xc0'| ./llvm-mc -disassemble -triple="x86_64" -x86-asm-syntax=intel I think those are all of the expected cases; movbe is still broken as of this build. |
mentioned in issue llvm/llvm-bugzilla-archive#10832 |
mentioned in issue llvm/llvm-bugzilla-archive#10988 |
Extended Description
From the "Intel® 64 and IA-32 Architectures Software Developer’s Manual
Volume 2 (2A & 2B): Instruction Set Reference, A-Z", p. 3-236:
CRC32 — Accumulate CRC32 Value
F2 0F 38 F0 /r
Clang on OSX assembles:
crc32 %al, %eax
To:
F2 0F 38 F0 C0
With llvm-mc built from trunk revision 135913:
$ echo '0xf2 0x0f 0x38 0xf0 0xc0'| ./llvm-mc -disassemble -triple="x86_64"
:1:1: warning: invalid instruction encoding
0xf2 0x0f 0x38 0xf0 0xc0
^
:1:21: warning: invalid instruction encoding
0xf2 0x0f 0x38 0xf0 0xc0
The text was updated successfully, but these errors were encountered: