maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/MC/Disassembler/X86/x86-64.txt

634 lines
12 KiB
Plaintext
Raw Normal View History

Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
# RUN: llvm-mc --disassemble %s -triple=x86_64 | FileCheck %s
# Coverage
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: vcmptrue_usps
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xc5 0x04 0xc2 0xc7 0x1f
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: vcmptrue_uspd
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xc5 0x05 0xc2 0xc7 0x1f
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: vcmptrue_usss
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xc5 0x06 0xc2 0xc7 0x1f
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: vcmptrue_ussd
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xc5 0x07 0xc2 0xc7 0x1f
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: vcmpeq_uqps
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xc5 0x04 0xc2 0xc7 0x08
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: vcmpeq_uqpd
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xc5 0x05 0xc2 0xc7 0x08
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: vcmpeq_uqss
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xc5 0x06 0xc2 0xc7 0x08
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: vcmpeq_uqsd
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xc5 0x07 0xc2 0xc7 0x08
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: vcmpeqps
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xc5 0x04 0xc2 0xc7 0x00
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: vcmpeqpd
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xc5 0x05 0xc2 0xc7 0x00
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: vcmpeqss
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xc5 0x06 0xc2 0xc7 0x00
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: vcmpeqsd
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xc5 0x07 0xc2 0xc7 0x00
[X86] Add VEX_WIG to VEX encoded version of VCMPPSY/VCMPPDY. llvm-svn: 330563
2018-04-23 12:50:01 +08:00
# CHECK: vcmptrue_usps %ymm7, %ymm15, %ymm0
0xc4 0xe1 0x84 0xc2 0xc7 0x1f
# CHECK: vcmptrue_uspd %ymm7, %ymm15, %ymm0
0xc4 0xe1 0x85 0xc2 0xc7 0x1f
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: cmpeqps
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0x0f 0xc2 0xc7 0x00
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: cmpeqpd
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0x66 0x0f 0xc2 0xc7 0x00
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: cmpeqss
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xf3 0x0f 0xc2 0xc7 0x00
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: cmpeqsd
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xf2 0x0f 0xc2 0xc7 0x00
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: cmpordps
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0x0f 0xc2 0xc7 0x07
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: cmpordpd
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0x66 0x0f 0xc2 0xc7 0x07
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: cmpordss
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xf3 0x0f 0xc2 0xc7 0x07
death to extra whitespace llvm-svn: 175200
2013-02-15 03:15:14 +08:00
# CHECK: cmpordsd
Add the tests that were supposed to go with r153935 that I forgot svn add llvm-svn: 154165
2012-04-06 15:09:59 +08:00
0xf2 0x0f 0xc2 0xc7 0x07
Add intrinsics, code gen, assembler and disassembler support for the SSE4a extrq and insertq instructions. This required light surgery on the assembler and disassembler because the instructions use an uncommon encoding. They are the only two instructions in x86 that use register operands and two immediates. llvm-svn: 157634
2012-05-30 03:05:25 +08:00
# CHECK: extrq $2, $3, %xmm0
0x66 0x0f 0x78 0xc0 0x03 0x02
# CHECK: extrq %xmm1, %xmm0
0x66 0x0f 0x79 0xc1
# CHECK: insertq $6, $5, %xmm1, %xmm0
0xf2 0x0f 0x78 0xc1 0x05 0x06
# CHECK: insertq %xmm1, %xmm0
0xf2 0x0f 0x79 0xc1
# CHECK: movntsd %xmm0, (%rdi)
0xf2 0x0f 0x2b 0x07
# CHECK: movntss %xmm0, (%rdi)
0xf3 0x0f 0x2b 0x07
added basic support for Intel ADX instructions -feature flag, instructions definitions, test cases llvm-svn: 175196
2013-02-15 03:08:21 +08:00
# CHECK: adcxl %eax, %eax
0x66 0x0f 0x38 0xf6 0xc0
# CHECK: adcxl (%rax), %eax
0x66 0x0f 0x38 0xf6 0x00
# CHECK: adcxq %rax, %rax
0x66 0x48 0x0f 0x38 0xf6 0xc0
# CHECK: adcxq (%rax), %rax
0x66 0x48 0x0f 0x38 0xf6 0x00
# CHECK: adoxl %eax, %eax
0xf3 0x0f 0x38 0xf6 0xc0
# CHECK: adoxl (%rax), %eax
0xf3 0x0f 0x38 0xf6 0x00
# CHECK: adoxq %rax, %rax
0xf3 0x48 0x0f 0x38 0xf6 0xc0
# CHECK: adoxq (%rax), %rax
0xf3 0x48 0x0f 0x38 0xf6 0x00
Fixes disassembler crashes on 2013 Haswell RTM instructions. rdar://13318048 llvm-svn: 176828
2013-03-12 05:17:13 +08:00
# CHECK: xbegin 53
0xc7 0xf8 0x35 0x00 0x00 0x00
[X86] Add OpSize32 to XBEGIN_4. Add XBEGIN_2 with OpSize16. Requires new AsmParserOperand types that detect 16-bit and 32/64-bit mode so that we choose the right instruction based on default sizing without predicates. This is necessary since predicates mess up the disassembler table building. llvm-svn: 225256
2015-01-06 16:59:30 +08:00
# CHECK: xbegin 53
0x66 0xc7 0xf8 0x35 0x00
Fixes disassembler crashes on 2013 Haswell RTM instructions. rdar://13318048 llvm-svn: 176828
2013-03-12 05:17:13 +08:00
# CHECK: xend
0x0f 0x01 0xd5
# CHECK: xabort $13
0xc6 0xf8 0x0d
fixed xsave, xsaveopt, xrstor mnemonics with intel syntax; added test cases llvm-svn: 179223
2013-04-11 05:52:25 +08:00
[X86] Make fxsave64/fxrstor64/xsave64/xsrstor64/xsaveopt64 parseable in AT&T syntax. Also make them the default output. llvm-svn: 227963
2015-02-03 19:03:57 +08:00
# CHECK: xsave64 (%rax)
fixed xsave, xsaveopt, xrstor mnemonics with intel syntax; added test cases llvm-svn: 179223
2013-04-11 05:52:25 +08:00
0x48 0x0f 0xae 0x20
[X86] Make fxsave64/fxrstor64/xsave64/xsrstor64/xsaveopt64 parseable in AT&T syntax. Also make them the default output. llvm-svn: 227963
2015-02-03 19:03:57 +08:00
# CHECK: xrstor64 (%rax)
fixed xsave, xsaveopt, xrstor mnemonics with intel syntax; added test cases llvm-svn: 179223
2013-04-11 05:52:25 +08:00
0x48 0x0f 0xae 0x28
[X86] Make fxsave64/fxrstor64/xsave64/xsrstor64/xsaveopt64 parseable in AT&T syntax. Also make them the default output. llvm-svn: 227963
2015-02-03 19:03:57 +08:00
# CHECK: xsaveopt64 (%rax)
fixed xsave, xsaveopt, xrstor mnemonics with intel syntax; added test cases llvm-svn: 179223
2013-04-11 05:52:25 +08:00
0x48 0x0f 0xae 0x30
Add CLAC/STAC instruction encoding/decoding support As these two instructions in AVX extension are privileged instructions for special purpose, it's only expected to be used in inlined assembly. llvm-svn: 179266
2013-04-11 12:52:28 +08:00
# CHECK: clac
0x0f 0x01 0xca
# CHECK: stac
0x0f 0x01 0xcb
Fix the move to/from accumulator register instructions that use a full 64-bit absolute address encoded in the instruction. rdar://8612627 and rdar://14299221 llvm-svn: 186878
2013-07-23 05:25:31 +08:00
# CHECK: movabsb -6066930261531658096, %al
0xa0 0x90 0x78 0x56 0x34 0x12 0xef 0xcd 0xab
# CHECK: movabsb -6066930261531658096, %al
0x48 0xa0 0x90 0x78 0x56 0x34 0x12 0xef 0xcd 0xab
# CHECK: movabsw -6066930261531658096, %ax
0x66 0xa1 0x90 0x78 0x56 0x34 0x12 0xef 0xcd 0xab
# CHECK: movabsl -6066930261531658096, %eax
0xa1 0x90 0x78 0x56 0x34 0x12 0xef 0xcd 0xab
# CHECK: movabsq -6066930261531658096, %rax
0x48 0xa1 0x90 0x78 0x56 0x34 0x12 0xef 0xcd 0xab
# CHECK: movabsb %al, -6066930261531658096
0xa2 0x90 0x78 0x56 0x34 0x12 0xef 0xcd 0xab
# CHECK: movabsb %al, -6066930261531658096
0x48 0xa2 0x90 0x78 0x56 0x34 0x12 0xef 0xcd 0xab
# CHECK: movabsw %ax, -6066930261531658096
0x66 0xa3 0x90 0x78 0x56 0x34 0x12 0xef 0xcd 0xab
# CHECK: movabsl %eax, -6066930261531658096
0xa3 0x90 0x78 0x56 0x34 0x12 0xef 0xcd 0xab
# CHECK: movabsq %rax, -6066930261531658096
0x48 0xa3 0x90 0x78 0x56 0x34 0x12 0xef 0xcd 0xab
Partial support for Intel SHA Extensions (sha1rnds4) Add basic assembly/disassembly support for the first Intel SHA instruction 'sha1rnds4'. Also includes feature flag, and test cases. Support for the remaining instructions will follow in a separate patch. llvm-svn: 190611
2013-09-12 23:51:31 +08:00
# CHECK: sha1rnds4 $1, %xmm1, %xmm2
0x0f 0x3a 0xcc 0xd1 0x01
# CHECK: sha1rnds4 $1, (%rax), %xmm2
Add the remaining Intel SHA instructions Also assembly/disassembly tests, and for sha256rnds2, aliases with an explicit xmm0 dependency. llvm-svn: 190754
2013-09-14 23:03:21 +08:00
0x0f 0x3a 0xcc 0x10 0x01
# CHECK: sha1nexte %xmm1, %xmm2
0x0f 0x38 0xc8 0xd1
# CHECK: sha1nexte (%rax), %xmm2
0x0f 0x38 0xc8 0x10
# CHECK: sha1msg1 %xmm1, %xmm2
0x0f 0x38 0xc9 0xd1
# CHECK: sha1msg1 (%rax), %xmm2
0x0f 0x38 0xc9 0x10
# CHECK: sha1msg2 %xmm1, %xmm2
0x0f 0x38 0xca 0xd1
# CHECK: sha1msg2 (%rax), %xmm2
0x0f 0x38 0xca 0x10
[X86] Fix printing of sha256rnds2 to include the implicit %xmm0 argument. llvm-svn: 294132
2017-02-06 02:33:31 +08:00
# CHECK: sha256rnds2 %xmm0, (%rax), %xmm2
Add the remaining Intel SHA instructions Also assembly/disassembly tests, and for sha256rnds2, aliases with an explicit xmm0 dependency. llvm-svn: 190754
2013-09-14 23:03:21 +08:00
0x0f 0x38 0xcb 0x10
[X86] Fix printing of sha256rnds2 to include the implicit %xmm0 argument. llvm-svn: 294132
2017-02-06 02:33:31 +08:00
# CHECK: sha256rnds2 %xmm0, %xmm1, %xmm2
Add the remaining Intel SHA instructions Also assembly/disassembly tests, and for sha256rnds2, aliases with an explicit xmm0 dependency. llvm-svn: 190754
2013-09-14 23:03:21 +08:00
0x0f 0x38 0xcb 0xd1
# CHECK: sha256msg1 %xmm1, %xmm2
0x0f 0x38 0xcc 0xd1
# CHECK: sha256msg1 (%rax), %xmm2
0x0f 0x38 0xcc 0x10
# CHECK: sha256msg2 %xmm1, %xmm2
0x0f 0x38 0xcd 0xd1
# CHECK: sha256msg2 (%rax), %xmm2
Add disassembler support for long encodings for INC/DEC in 32-bit mode. llvm-svn: 192086
2013-10-07 12:28:06 +08:00
0x0f 0x38 0xcd 0x10
# CHECK: incl %ecx
0xff 0xc1
# CHECK: decl %ecx
0xff 0xc9
# CHECK: incw %cx
0x66 0xff 0xc1
# CHECK: decw %cx
0x66 0xff 0xc9
# CHECK: incb %cl
0xfe 0xc1
# CHECK: decb %cl
0xfe 0xc9
# CHECK: incq %rcx
0x48 0xff 0xc1
# CHECK: decq %rcx
0x48 0xff 0xc9
Remove some instructions that seem to only exist to trick the filtering checks in the disassembler table creation. Just fix up the filter to let the real instruction through instead. llvm-svn: 192090
2013-10-07 15:19:47 +08:00
# CHECK: movq %xmm0, %xmm0
0xf3 0x0f 0x7e 0xc0
# CHECK: vmovq %xmm0, %xmm0
0xc5 0xfa 0x7e 0xc0
Remove some instructions that existed to provide aliases to the assembler. Can be done with InstAlias instead. Unfortunately, this was causing printer to use 'vmovq' or 'vmovd' based on what was parsed. To cleanup the inconsistencies convert all 'vmovd' with 64-bit registers to 'vmovq', but provide an alias so that 'vmovd' will still parse. llvm-svn: 192171
2013-10-08 13:53:50 +08:00
# CHECK: vmovq %xmm0, %rax
0xc4 0xe1 0xf9 0x7e 0xc0
[X86] Stop printing moves between VR64 and GR64 with 'movd' mnemonic. Use 'movq' instead. This behavior existed to work with an old version of the gnu assembler on MacOS that only accepted this form. Newer versions of GNU assembler and the current LLVM derived version of the assembler on MacOS support movq as well. llvm-svn: 321898
2018-01-06 04:55:12 +08:00
# CHECK: movq (%rax), %mm0
[X86] Add some missing redundant MMX and SSE encodings for disassembler. llvm-svn: 230165
2015-02-22 15:50:41 +08:00
0x48 0x0f 0x6e 0x00
[X86] Stop printing moves between VR64 and GR64 with 'movd' mnemonic. Use 'movq' instead. This behavior existed to work with an old version of the gnu assembler on MacOS that only accepted this form. Newer versions of GNU assembler and the current LLVM derived version of the assembler on MacOS support movq as well. llvm-svn: 321898
2018-01-06 04:55:12 +08:00
# CHECK: movq %rax, %mm0
[X86] Add some missing redundant MMX and SSE encodings for disassembler. llvm-svn: 230165
2015-02-22 15:50:41 +08:00
0x48 0x0f 0x6e 0xc0
[X86] Stop printing moves between VR64 and GR64 with 'movd' mnemonic. Use 'movq' instead. This behavior existed to work with an old version of the gnu assembler on MacOS that only accepted this form. Newer versions of GNU assembler and the current LLVM derived version of the assembler on MacOS support movq as well. llvm-svn: 321898
2018-01-06 04:55:12 +08:00
# CHECK: movq %mm0, (%rax)
[X86] Add some missing redundant MMX and SSE encodings for disassembler. llvm-svn: 230165
2015-02-22 15:50:41 +08:00
0x48 0x0f 0x7e 0x00
[X86] Stop printing moves between VR64 and GR64 with 'movd' mnemonic. Use 'movq' instead. This behavior existed to work with an old version of the gnu assembler on MacOS that only accepted this form. Newer versions of GNU assembler and the current LLVM derived version of the assembler on MacOS support movq as well. llvm-svn: 321898
2018-01-06 04:55:12 +08:00
# CHECK: movq %mm0, %rax
[X86] Add some missing redundant MMX and SSE encodings for disassembler. llvm-svn: 230165
2015-02-22 15:50:41 +08:00
0x48 0x0f 0x7e 0xc0
[X86][SSE2] Fix asm string for movq (Move Quadword) instruction. Replace "mov{d|q}" with "movq". Differential Revision: https://reviews.llvm.org/D32220 llvm-svn: 301386
2017-04-26 15:08:44 +08:00
# CHECK: movq (%rax), %xmm0
[X86] Add some missing redundant MMX and SSE encodings for disassembler. llvm-svn: 230165
2015-02-22 15:50:41 +08:00
0x66 0x48 0x0f 0x6e 0x00
[X86][SSE2] Fix asm string for movq (Move Quadword) instruction. Replace "mov{d|q}" with "movq". Differential Revision: https://reviews.llvm.org/D32220 llvm-svn: 301386
2017-04-26 15:08:44 +08:00
# CHECK: movq %rax, %xmm0
[X86] Add some missing redundant MMX and SSE encodings for disassembler. llvm-svn: 230165
2015-02-22 15:50:41 +08:00
0x66 0x48 0x0f 0x6e 0xc0
[X86][SSE2] Fix asm string for movq (Move Quadword) instruction. Replace "mov{d|q}" with "movq". Differential Revision: https://reviews.llvm.org/D32220 llvm-svn: 301386
2017-04-26 15:08:44 +08:00
# CHECK: movq %xmm0, (%rax)
[X86] Add some missing redundant MMX and SSE encodings for disassembler. llvm-svn: 230165
2015-02-22 15:50:41 +08:00
0x66 0x48 0x0f 0x7e 0x00
[X86][SSE2] Fix asm string for movq (Move Quadword) instruction. Replace "mov{d|q}" with "movq". Differential Revision: https://reviews.llvm.org/D32220 llvm-svn: 301386
2017-04-26 15:08:44 +08:00
# CHECK: movq %xmm0, %rax
Remove some instructions that existed to provide aliases to the assembler. Can be done with InstAlias instead. Unfortunately, this was causing printer to use 'vmovq' or 'vmovd' based on what was parsed. To cleanup the inconsistencies convert all 'vmovd' with 64-bit registers to 'vmovq', but provide an alias so that 'vmovd' will still parse. llvm-svn: 192171
2013-10-08 13:53:50 +08:00
0x66 0x48 0x0f 0x7e 0xc0
Add disassembler support for SSE4.1 register/register form of PEXTRW. There is a shorter encoding that was part of SSE2, but a memory form was added in SSE4.1. This is the register form of that encoding. llvm-svn: 192566
2013-10-14 09:42:32 +08:00
# CHECK: pextrw $3, %xmm3, %ecx
0x66 0x0f 0x3a 0x15 0xd9 0x03
# CHECK: pextrw $3, %xmm3, (%rax)
0x66 0x0f 0x3a 0x15 0x18 0x03
Fix diassembler handling of rex.b when mod=00/01/10 and bbb=101. Mod=00 should ignore the base register entirely. Mod=01/10 should treat this as R13 plus displacment. Fixes PR18860. llvm-svn: 201507
2014-02-17 18:03:43 +08:00
[X86] Teach the disassembler to use %eiz/%riz instead of NoRegister when the SIB byte is present, but doesn't encode an index register and there was another shorter encoding that would achieve the same result. The %eiz/%riz are dummy registers that force the encoder to emit a SIB byte when it normally wouldn't. By emitting them in the disassembly output we ensure that assembling the disassembler output would also produce a SIB byte. This should match the behavior of objdump from binutils. llvm-svn: 335768
2018-06-28 03:03:36 +08:00
# CHECK: addb $0, 305419896(,%r8)
Fix diassembler handling of rex.b when mod=00/01/10 and bbb=101. Mod=00 should ignore the base register entirely. Mod=01/10 should treat this as R13 plus displacment. Fixes PR18860. llvm-svn: 201507
2014-02-17 18:03:43 +08:00
0x43 0x80 0x04 0x05 0x78 0x56 0x34 0x12 0x00
[X86] Teach the disassembler to use %eiz/%riz instead of NoRegister when the SIB byte is present, but doesn't encode an index register and there was another shorter encoding that would achieve the same result. The %eiz/%riz are dummy registers that force the encoder to emit a SIB byte when it normally wouldn't. By emitting them in the disassembly output we ensure that assembling the disassembler output would also produce a SIB byte. This should match the behavior of objdump from binutils. llvm-svn: 335768
2018-06-28 03:03:36 +08:00
# CHECK: addb $0, 305419896(%r13,%r8)
Fix diassembler handling of rex.b when mod=00/01/10 and bbb=101. Mod=00 should ignore the base register entirely. Mod=01/10 should treat this as R13 plus displacment. Fixes PR18860. llvm-svn: 201507
2014-02-17 18:03:43 +08:00
0x43 0x80 0x84 0x05 0x78 0x56 0x34 0x12 0x00
[X86] Teach the disassembler to use %eiz/%riz instead of NoRegister when the SIB byte is present, but doesn't encode an index register and there was another shorter encoding that would achieve the same result. The %eiz/%riz are dummy registers that force the encoder to emit a SIB byte when it normally wouldn't. By emitting them in the disassembly output we ensure that assembling the disassembler output would also produce a SIB byte. This should match the behavior of objdump from binutils. llvm-svn: 335768
2018-06-28 03:03:36 +08:00
# CHECK: addb $0, 305419896(,%r8)
Fix diassembler handling of rex.b when mod=00/01/10 and bbb=101. Mod=00 should ignore the base register entirely. Mod=01/10 should treat this as R13 plus displacment. Fixes PR18860. llvm-svn: 201507
2014-02-17 18:03:43 +08:00
0x42 0x80 0x04 0x05 0x78 0x56 0x34 0x12 0x00
[X86] Teach the disassembler to use %eiz/%riz instead of NoRegister when the SIB byte is present, but doesn't encode an index register and there was another shorter encoding that would achieve the same result. The %eiz/%riz are dummy registers that force the encoder to emit a SIB byte when it normally wouldn't. By emitting them in the disassembly output we ensure that assembling the disassembler output would also produce a SIB byte. This should match the behavior of objdump from binutils. llvm-svn: 335768
2018-06-28 03:03:36 +08:00
# CHECK: addb $0, 305419896(%rbp,%r8)
Fix diassembler handling of rex.b when mod=00/01/10 and bbb=101. Mod=00 should ignore the base register entirely. Mod=01/10 should treat this as R13 plus displacment. Fixes PR18860. llvm-svn: 201507
2014-02-17 18:03:43 +08:00
0x42 0x80 0x84 0x05 0x78 0x56 0x34 0x12 0x00
[X86] Teach the disassembler to use %eiz/%riz instead of NoRegister when the SIB byte is present, but doesn't encode an index register and there was another shorter encoding that would achieve the same result. The %eiz/%riz are dummy registers that force the encoder to emit a SIB byte when it normally wouldn't. By emitting them in the disassembly output we ensure that assembling the disassembler output would also produce a SIB byte. This should match the behavior of objdump from binutils. llvm-svn: 335768
2018-06-28 03:03:36 +08:00
# CHECK: addb $0, 305419896(,%r12)
Fix diassembler handling of rex.b when mod=00/01/10 and bbb=101. Mod=00 should ignore the base register entirely. Mod=01/10 should treat this as R13 plus displacment. Fixes PR18860. llvm-svn: 201507
2014-02-17 18:03:43 +08:00
0x42 0x80 0x04 0x25 0x78 0x56 0x34 0x12 0x00
[X86] Teach the disassembler to use %eiz/%riz instead of NoRegister when the SIB byte is present, but doesn't encode an index register and there was another shorter encoding that would achieve the same result. The %eiz/%riz are dummy registers that force the encoder to emit a SIB byte when it normally wouldn't. By emitting them in the disassembly output we ensure that assembling the disassembler output would also produce a SIB byte. This should match the behavior of objdump from binutils. llvm-svn: 335768
2018-06-28 03:03:36 +08:00
# CHECK: addb $0, 305419896(%rbp,%r12)
Fix diassembler handling of rex.b when mod=00/01/10 and bbb=101. Mod=00 should ignore the base register entirely. Mod=01/10 should treat this as R13 plus displacment. Fixes PR18860. llvm-svn: 201507
2014-02-17 18:03:43 +08:00
0x42 0x80 0x84 0x25 0x78 0x56 0x34 0x12 0x00
[X86] Teach the disassembler to use %eiz/%riz instead of NoRegister when the SIB byte is present, but doesn't encode an index register and there was another shorter encoding that would achieve the same result. The %eiz/%riz are dummy registers that force the encoder to emit a SIB byte when it normally wouldn't. By emitting them in the disassembly output we ensure that assembling the disassembler output would also produce a SIB byte. This should match the behavior of objdump from binutils. llvm-svn: 335768
2018-06-28 03:03:36 +08:00
# CHECK: addb $0, 305419896
Fix diassembler handling of rex.b when mod=00/01/10 and bbb=101. Mod=00 should ignore the base register entirely. Mod=01/10 should treat this as R13 plus displacment. Fixes PR18860. llvm-svn: 201507
2014-02-17 18:03:43 +08:00
0x80 0x04 0x25 0x78 0x56 0x34 0x12 0x00
[X86] Teach the disassembler to use %eiz/%riz instead of NoRegister when the SIB byte is present, but doesn't encode an index register and there was another shorter encoding that would achieve the same result. The %eiz/%riz are dummy registers that force the encoder to emit a SIB byte when it normally wouldn't. By emitting them in the disassembly output we ensure that assembling the disassembler output would also produce a SIB byte. This should match the behavior of objdump from binutils. llvm-svn: 335768
2018-06-28 03:03:36 +08:00
# CHECK: addb $0, 305419896(%rbp)
0x80 0x85 0x78 0x56 0x34 0x12 0x00
# CHECK: addb $0, 305419896(%rbp,%riz)
Fix diassembler handling of rex.b when mod=00/01/10 and bbb=101. Mod=00 should ignore the base register entirely. Mod=01/10 should treat this as R13 plus displacment. Fixes PR18860. llvm-svn: 201507
2014-02-17 18:03:43 +08:00
0x80 0x84 0x25 0x78 0x56 0x34 0x12 0x00
[X86] Disassembler support for move to/from %rax with a 32-bit memory offset is REX.W and AdSize prefix are both present. llvm-svn: 225099
2015-01-03 08:00:20 +08:00
[X86] Teach the disassembler to use %eiz/%riz instead of NoRegister when the SIB byte is present, but doesn't encode an index register and there was another shorter encoding that would achieve the same result. The %eiz/%riz are dummy registers that force the encoder to emit a SIB byte when it normally wouldn't. By emitting them in the disassembly output we ensure that assembling the disassembler output would also produce a SIB byte. This should match the behavior of objdump from binutils. llvm-svn: 335768
2018-06-28 03:03:36 +08:00
# CHECK: addb $0, 305419896(%rbp,%riz,2)
0x80 0x84 0x65 0x78 0x56 0x34 0x12 0x00
# CHECK: addb $0, 305419896(%rsp,%riz,2)
0x80 0x84 0x64 0x78 0x56 0x34 0x12 0x00
# CHECK: addb $0, 305419896(%r12,%riz,2)
0x41 0x80 0x84 0x64 0x78 0x56 0x34 0x12 0x00
# CHECK: addb $0, 305419896(%esp,%eiz,2)
0x67 0x80 0x84 0x64 0x78 0x56 0x34 0x12 0x00
# CHECK: addb $0, 305419896(%r12d,%eiz,2)
0x67 0x41 0x80 0x84 0x64 0x78 0x56 0x34 0x12 0x00
[X86] Disassembler support for move to/from %rax with a 32-bit memory offset is REX.W and AdSize prefix are both present. llvm-svn: 225099
2015-01-03 08:00:20 +08:00
# CHECK: movabsq 6510615555426900570, %rax
0x48 0xa1 0x5a 0x5a 0x5a 0x5a 0x5a 0x5a 0x5a 0x5a
# CHECK: movq 1515870810, %rax
0x67, 0x48 0xa1 0x5a 0x5a 0x5a 0x5a
# CHECK: movabsq %rax, 6510615555426900570
0x48 0xa3 0x5a 0x5a 0x5a 0x5a 0x5a 0x5a 0x5a 0x5a
# CHECK: movq %rax, 1515870810
0x67, 0x48 0xa3 0x5a 0x5a 0x5a 0x5a
[X86] Fix PR23271 - RIP-relative decoding bug in disassembler. Differential Revision: http://reviews.llvm.org/D9110 llvm-svn: 237310
2015-05-14 06:44:52 +08:00
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: callw 32767
0x66 0xe8 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: callw 32767
0x66 0x66 0x48 0xe8 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: jmp -32769
0xe9 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: jmp 32767
0x66 0xe9 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: jmp 32767
0x66 0x66 0x48 0xe9 0xff 0x7f
# CHECK: jo -32769
0x0f 0x80 0xff 0x7f 0xff 0xff
# CHECK: jo 32767
0x66 0x0f 0x80 0xff 0x7f
# CHECK: jno -32769
0x0f 0x81 0xff 0x7f 0xff 0xff
# CHECK: jno 32767
0x66 0x0f 0x81 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: jb -32769
0x0f 0x82 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: jb 32767
0x66 0x0f 0x82 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: jae -32769
0x0f 0x83 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: jae 32767
0x66 0x0f 0x83 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: je -32769
0x0f 0x84 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: je 32767
0x66 0x0f 0x84 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: jne -32769
0x0f 0x85 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: jne 32767
0x66 0x0f 0x85 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: jbe -32769
0x0f 0x86 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: jbe 32767
0x66 0x0f 0x86 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: ja -32769
0x0f 0x87 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: ja 32767
0x66 0x0f 0x87 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: js -32769
0x0f 0x88 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: js 32767
0x66 0x0f 0x88 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: jns -32769
0x0f 0x89 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: jns 32767
0x66 0x0f 0x89 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: jp -32769
0x0f 0x8a 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: jp 32767
0x66 0x0f 0x8a 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: jnp -32769
0x0f 0x8b 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: jnp 32767
0x66 0x0f 0x8b 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: jl -32769
0x0f 0x8c 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: jl 32767
0x66 0x0f 0x8c 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: jge -32769
0x0f 0x8d 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: jge 32767
0x66 0x0f 0x8d 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: jle -32769
0x0f 0x8e 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: jle 32767
0x66 0x0f 0x8e 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: jg -32769
0x0f 0x8f 0xff 0x7f 0xff 0xff
[X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
2018-08-14 06:06:28 +08:00
# CHECK: jg 32767
0x66 0x0f 0x8f 0xff 0x7f
[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly This is a fix for disassembling unusual instruction sequences in 64-bit mode w.r.t the CALL rel16 instruction. It might be desirable to move the check somewhere else, but it essentially mimics the special case handling with JCXZ in 16-bit mode. The current behavior accepts the opcode size prefix and causes the call's immediate to stop disassembling after 2 bytes. When debugging sequences of instructions with this pattern, the disassembler output becomes extremely unreliable and essentially useless (if you jump midway into what lldb thinks is a unified instruction, you'll lose %rip). So we ignore the prefix and consume all 4 bytes when disassembling a 64-bit mode binary. Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S. is defined as: Indicates an instruction syntax that requires an address override prefix in 64-bit mode and is not supported. Using an address override prefix in 64-bit mode may result in model-specific execution behavior. (Vol. 2A 3-7) Since 0x66 is an operand override prefix we should be OK (although we may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested with, they all ignore the 0x66 prefix in 64-bit mode. Patch by Matthew Barney! Differential Revision: http://reviews.llvm.org/D9573 llvm-svn: 246038
2015-08-27 00:20:29 +08:00
# CHECK: lcallw *-32769(%rip)
0x66 0xff 0x1d 0xff 0x7f 0xff 0xff
# CHECK: ljmpw *-32769(%rip)
0x66 0xff 0x2d 0xff 0x7f 0xff 0xff
# CHECK: psubsb (%rdx), %mm3
0x0f 0xe8 0x1a
# CHECK: psubsb (%rdx), %xmm3
0x66 0x0f 0xe8 0x1a
[X86] Fix PR23271 - RIP-relative decoding bug in disassembler. Differential Revision: http://reviews.llvm.org/D9110 llvm-svn: 237310
2015-05-14 06:44:52 +08:00
# CHECK: addq 255(%rip), %rbx
0x49, 0x03, 0x1d, 0xff, 0x00, 0x00, 0x00
# The following 4 encodings are equivalent, as confirmed by the 'xed64'
# decoder tool provided by Intel, which we assume to be canonical even
# if the real silicon does something different. If that should happen,
# then we'll all have disassembler bugs to repair.
# Try all combinations of EVEX.x and REX.b:
# CHECK: vaddps 287453952(%rip), %zmm20, %zmm15
0x62 0x11 0x5c 0x40 0x58 0x3d 0x00 0x33 0x22 0x11
# CHECK: vaddps 287453952(%rip), %zmm20, %zmm15
0x62 0x31 0x5c 0x40 0x58 0x3d 0x00 0x33 0x22 0x11
# CHECK: vaddps 287453952(%rip), %zmm20, %zmm15
0x62 0x51 0x5c 0x40 0x58 0x3d 0x00 0x33 0x22 0x11
# CHECK: vaddps 287453952(%rip), %zmm20, %zmm15
0x62 0x71 0x5c 0x40 0x58 0x3d 0x00 0x33 0x22 0x11
[X86] Fix disassembling of EVEX instructions to stop accidentally decoding the SIB index register as an XMM/YMM/ZMM register. This introduces a new operand type to encode the whether the index register should be XMM/YMM/ZMM. And new code to fixup the results created by readSIB. This has the nice effect of removing a bunch of code that hard coded the name of every GATHER and SCATTER instruction to map the index type. This fixes PR32807. llvm-svn: 316273
2017-10-22 04:03:20 +08:00
# CHECK: vaddps (%r10,%r9), %zmm20, %zmm15
[X86] Fix PR23271 - RIP-relative decoding bug in disassembler. Differential Revision: http://reviews.llvm.org/D9110 llvm-svn: 237310
2015-05-14 06:44:52 +08:00
0x62 0x11 0x5c 0x40 0x58 0x3c 0x0a
[X86] Fix disassembling of EVEX instructions to stop accidentally decoding the SIB index register as an XMM/YMM/ZMM register. This introduces a new operand type to encode the whether the index register should be XMM/YMM/ZMM. And new code to fixup the results created by readSIB. This has the nice effect of removing a bunch of code that hard coded the name of every GATHER and SCATTER instruction to map the index type. This fixes PR32807. llvm-svn: 316273
2017-10-22 04:03:20 +08:00
# CHECK: vaddps (%rdx,%r9), %zmm20, %zmm15
[X86] Fix PR23271 - RIP-relative decoding bug in disassembler. Differential Revision: http://reviews.llvm.org/D9110 llvm-svn: 237310
2015-05-14 06:44:52 +08:00
0x62 0x31 0x5c 0x40 0x58 0x3c 0x0a
[X86] Fix disassembling of EVEX instructions to stop accidentally decoding the SIB index register as an XMM/YMM/ZMM register. This introduces a new operand type to encode the whether the index register should be XMM/YMM/ZMM. And new code to fixup the results created by readSIB. This has the nice effect of removing a bunch of code that hard coded the name of every GATHER and SCATTER instruction to map the index type. This fixes PR32807. llvm-svn: 316273
2017-10-22 04:03:20 +08:00
# CHECK: vaddps (%r10,%rcx), %zmm20, %zmm15
[X86] Fix PR23271 - RIP-relative decoding bug in disassembler. Differential Revision: http://reviews.llvm.org/D9110 llvm-svn: 237310
2015-05-14 06:44:52 +08:00
0x62 0x51 0x5c 0x40 0x58 0x3c 0x0a
[X86] Fix disassembling of EVEX instructions to stop accidentally decoding the SIB index register as an XMM/YMM/ZMM register. This introduces a new operand type to encode the whether the index register should be XMM/YMM/ZMM. And new code to fixup the results created by readSIB. This has the nice effect of removing a bunch of code that hard coded the name of every GATHER and SCATTER instruction to map the index type. This fixes PR32807. llvm-svn: 316273
2017-10-22 04:03:20 +08:00
# CHECK: vaddps (%rdx,%rcx), %zmm20, %zmm15
[X86] Fix PR23271 - RIP-relative decoding bug in disassembler. Differential Revision: http://reviews.llvm.org/D9110 llvm-svn: 237310
2015-05-14 06:44:52 +08:00
0x62 0x71 0x5c 0x40 0x58 0x3c 0x0a
[X86]: Correctly sign-extend 16-bit immediate in CALL instruction. Patch by Matthew Barney. Thanks! Differential Revision: http://reviews.llvm.org/D9514 llvm-svn: 240795
2015-06-27 00:58:59 +08:00
[MC][X86] Add teet case from PR32807 llvm-svn: 318603
2017-11-19 07:06:42 +08:00
# CHECK: vpandd 32(%rsi,%r14,4){1to16}, %zmm26, %zmm21 {%k4} {z}
0x62 0xa1 0x2d 0xd4 0xdb 0x6c 0xb6 0x08
[X86]: Correctly sign-extend 16-bit immediate in CALL instruction. Patch by Matthew Barney. Thanks! Differential Revision: http://reviews.llvm.org/D9514 llvm-svn: 240795
2015-06-27 00:58:59 +08:00
# CHECK: callq 32767
0xe8 0xff 0x7f 0x00 0x00
# CHECK: callq -32769
0xe8 0xff 0x7f 0xff 0xff
[X86][LWP] Add llvm support for LWP instructions (reapplied). This patch adds support for the the LightWeight Profiling (LWP) instructions which are available on all AMD Bulldozer class CPUs (bdver1 to bdver4). Reapplied - this time without changing line endings of existing files. Differential Revision: https://reviews.llvm.org/D32769 llvm-svn: 302041
2017-05-03 23:51:39 +08:00
# CHECK: llwpcb %rax
0x8f 0xe9 0xf8 0x12 0xc0
# CHECK: slwpcb %rax
0x8f 0xe9 0xf8 0x12 0xc8
# CHECK: lwpins $305419896, %ebx, %rax
0x8f 0xea 0xf8 0x12 0xc3 0x78 0x56 0x34 0x12
# CHECK: lwpins $591751049, (%rsp), %rdx
0x8f 0xea 0xe8 0x12 0x04 0x24 0x89 0x67 0x45 0x23
# CHECK: lwpins $591751049, (%esp), %edx
0x67 0x8f 0xea 0x68 0x12 0x04 0x24 0x89 0x67 0x45 0x23
# CHECK: lwpval $1737075661, %ebx, %rax
0x8f 0xea 0xf8 0x12 0xcb 0xcd 0xab 0x89 0x67
# CHECK: lwpval $2309737967, (%rsp), %rdx
0x8f 0xea 0xe8 0x12 0x0c 0x24 0xef 0xcd 0xab 0x89
# CHECK: lwpval $2309737967, (%esp), %edx
0x67 0x8f 0xea 0x68 0x12 0x0c 0x24 0xef 0xcd 0xab 0x89
[X86] Add nopq instruction which is a rex encoded version of nopl for gas compatibility. llvm-svn: 308818
2017-07-22 09:30:53 +08:00
# CHECK: nopq -559038737(%rbx,%rcx,8)
0x48 0x0f 0x1f 0x84 0xcb 0xef 0xbe 0xad 0xde
# CHECK: nopq %rax
0x48 0x0f 0x1f 0xC0
This patch is a result of D37262: The issues with X86 prefixes. It closes PR7709, PR17697, PR19251, PR32809 and PR21640. There could be other bugs closed by this patch. llvm-svn: 315899
2017-10-16 19:14:29 +08:00
Invalid used of 'w' suffix on push and pop using 64-bit register. Differential Revision: https://reviews.llvm.org/D38626 llvm-svn: 316898
2017-10-30 20:02:06 +08:00
# CHECK: popq %r14
It's a test to demonstrate wrong disassembler with 0x67 prefix llvm-svn: 316655
2017-10-26 19:14:43 +08:00
0x67 0x49 0x5e
Invalid used of 'w' suffix on push and pop using 64-bit register. Differential Revision: https://reviews.llvm.org/D38626 llvm-svn: 316898
2017-10-30 20:02:06 +08:00
# CHECK: pushq %r14
It's a test to demonstrate wrong disassembler with 0x67 prefix llvm-svn: 316655
2017-10-26 19:14:43 +08:00
0x67 0x49 0x56
This patch is a result of D37262: The issues with X86 prefixes. It closes PR7709, PR17697, PR19251, PR32809 and PR21640. There could be other bugs closed by this patch. llvm-svn: 315899
2017-10-16 19:14:29 +08:00
# CHECK: xchgw %di, %ax
0x66 0x3e 0x97
Fix for Bug 30718 - Failure to disassemble certain MOV with rex.R. The issue was in illegal segment register index. Differential Revision: https://reviews.llvm.org/D38786 llvm-svn: 316319
2017-10-23 17:36:33 +08:00
# CHECK: movq %rdx, %cs
0x4c 0x8e 0xca
This patch is a result of D37262: The issues with X86 prefixes. It closes PR7709, PR17697, PR19251, PR32809 and PR21640. There could be other bugs closed by this patch. llvm-svn: 315899
2017-10-16 19:14:29 +08:00
# CHECK: movw %bx, %cs:(%rsi,%rbp)
0x2e 0x66 0x89 0x1c 0x2e
# CHECK: movl %ebx, %cs:(%esi,%ebp)
0x2e 0x67 0x89 0x1c 0x2e
# CHECK: movl %ebx, %cs:(%rsi,%rbp)
0x2e 0x89 0x1c 0x2e
# CHECK: movw %bx, %cs:(%esi,%ebp)
0x2e 0x67 0x66 0x89 0x1c 0x2e
# CHECK: movw %bx, %cs:(%esi,%ebp)
0x2e 0x66 0x67 0x89 0x1c 0x2e
[X86] Add PTWRITE instruction for assembler and disassembler. llvm-svn: 316333
2017-10-23 23:53:21 +08:00
# CHECK: ptwritel -559038737(%rbx,%rcx,8)
0xf3 0x0f 0xae 0xa4 0xcb 0xef 0xbe 0xad 0xde
# CHECK: ptwritel %eax
0xf3 0x0f 0xae 0xe0
# CHECK: ptwriteq -559038737(%rbx,%rcx,8)
0xf3 0x48 0x0f 0xae 0xa4 0xcb 0xef 0xbe 0xad 0xde
# CHECK: ptwriteq %rax
0xf3 0x48 0x0f 0xae 0xe0
[X86] Describe wbnoinvd instruction Similar to the wbinvd instruction, except this one does not invalidate caches. Ring 0 only. The encoding matches a wbinvd instruction with an F3 prefix. Reviewers: craig.topper, zvi, ashlykov Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D43816 llvm-svn: 329847
2018-04-12 04:01:57 +08:00
# CHECK: wbnoinvd
0xf3 0x0f 0x09
[X86] Introduce cldemote instruction Hint to hardware to move the cache line containing the address to a more distant level of the cache without writing back to memory. Reviewers: craig.topper, zvi Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D45256 llvm-svn: 329992
2018-04-13 15:35:08 +08:00
# CHECK: cldemote 4(%rax)
0x0f 0x1c 0x40 0x04
# CHECK: cldemote -559038737(%rbx,%rcx,8)
0x0f,0x1c,0x84,0xcb,0xef,0xbe,0xad,0xde
[X86] WaitPKG instructions Three new instructions: umonitor - Sets up a linear address range to be monitored by hardware and activates the monitor. The address range should be a writeback memory caching type. umwait - A hint that allows the processor to stop instruction execution and enter an implementation-dependent optimized state until occurrence of a class of events. tpause - Directs the processor to enter an implementation-dependent optimized state until the TSC reaches the value in EDX:EAX. Also modifying the description of the mfence instruction, as the rep prefix (0xF3) was allowed before, which would conflict with umonitor during disassembly. Before: $ echo 0xf3,0x0f,0xae,0xf0 | llvm-mc -disassemble .text mfence After: $ echo 0xf3,0x0f,0xae,0xf0 | llvm-mc -disassemble .text umonitor %rax Reviewers: craig.topper, zvi Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D45253 llvm-svn: 330462
2018-04-21 02:42:47 +08:00
# CHECK: umonitor %rax
0xf3 0x0f 0xae 0xf0
# CHECK: umonitor %eax
0x67 0xf3 0x0f 0xae 0xf0
# CHECK: umonitor %r13
0xf3 0x41 0x0f 0xae 0xf5
# CHECK: umwait %r15
0xf2 0x41 0x0f 0xae 0xf7
# CHECK: tpause %r15
0x66 0x41 0x0f 0xae 0xf7
[X86] Add disassembler test cases for bswap. This demonstrates a bug where the encoding for a 16-bit bswap prints a 16-bit register and a 32-bit mnemonic. Intel docs say 16-bit bswap is undefined. We should either claim it as an invalid encoding or we should print a 16-bit mnemonic. objdump does print the encoding as bswap with a 16-bit register. But it doesn't seem to ever print a suffix. llvm-svn: 330621
2018-04-24 01:47:33 +08:00
[X86] Add a BSWAP16 instruction using the 32-bit encoding plus a 0x66 prefix. This encoding is recognized by the CPU, but the behavior is undefined. This makes the disassembler handle it correctly so we don't print bswapl with a 16-bit register. llvm-svn: 330682
2018-04-24 12:28:02 +08:00
# CHECK: bswapw %bx
[X86] Add disassembler test cases for bswap. This demonstrates a bug where the encoding for a 16-bit bswap prints a 16-bit register and a 32-bit mnemonic. Intel docs say 16-bit bswap is undefined. We should either claim it as an invalid encoding or we should print a 16-bit mnemonic. objdump does print the encoding as bswap with a 16-bit register. But it doesn't seem to ever print a suffix. llvm-svn: 330621
2018-04-24 01:47:33 +08:00
0x66 0x0f 0xcb
# CHECK: bswapl %ebx
0x0f 0xcb
# CHECK: bswapq %rbx
0x48 0x0f 0xcb
[X86] movdiri and movdir64b instructions Reviewers: spatel, craig.topper, RKSimon Reviewed By: craig.topper, RKSimon Differential Revision: https://reviews.llvm.org/D45983 llvm-svn: 331248
2018-05-01 18:01:16 +08:00
#CHECK: movdiri %r13d, 64(%rdx,%rax,4)
0x44 0x0f 0x38 0xf9 0x6c 0x82 0x40
#CHECK: movdir64b 485498096, %rax
0x66 0x0f 0x38 0xf8 0x04 0x25 0xf0 0x1c 0xf0 0x1c
#CHECK: movdir64b 485498096, %eax
0x67 0x66 0x0f 0x38 0xf8 0x04 0x25 0xf0 0x1c 0xf0 0x1c
[x86] Introduce the pconfig instruction Reviewers: craig.topper, zvi Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D46430 llvm-svn: 331739
2018-05-08 14:47:36 +08:00
#CHECK: pconfig
0x0f 0x01 0xc5
[x86] Introduce the enclv instruction Summary: and use the -msgx flag as a requirement for the SGX instructions. Reviewers: craig.topper, zvi Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D46436 llvm-svn: 331742
2018-05-08 15:11:05 +08:00
#CHECK: encls
0x0f 0x01 0xcf
#CHECK: enclu
0x0f 0x01 0xd7
#CHECK: enclv
0x0f 0x01 0xc0
[X86][Disassembler] Make sure EVEX.X is not used to extend base registers of memory operations. This was an accidental side effect of EVEX.X being used to encode XMM16-XMM31 using modrm.rm with modrm.mod==0x3. I think there are still more bugs related to this. llvm-svn: 333722
2018-06-01 12:29:34 +08:00
# Make sure we ignore EVEX.X when the index register isn't being used.
#CHECK: vaddps (%rax), %xmm16, %xmm1
0x62 0xb1 0x7c 0x00 0x58 0x08
[X86] Add a test case showing a bad disassembling of an EVEX instruction with EVEX.X=0 and a GPR encoded in modrm.rm. EVEX.X is used to extended modrm.rm when the instruction encodes a XMM/YMM/ZMM register. But we aren't properly ignoring it when it encodes a GPR and we end up printing whatever registers exist in X86 register enum after the GPRs. llvm-svn: 333724
2018-06-01 13:12:43 +08:00
[X86][Disassembler] Ignore EVEX.X extension of modrm.rm to 5-bits when modrm.rm encodes a k-register. llvm-svn: 333727
2018-06-01 13:36:08 +08:00
# Make sure we ignore EVEX.X when modrm.rm encodes a GPR.
[X86][Disassembler] Clamp index to 4-bits when decoding GPR registers. A 5-bit value can occur when EVEX.X is 0 due to it being used to extend modrm.rm to encode XMM16-31. But if modrm.rm instead encodes a GPR, the Intel documentation says EVEX.X should be ignored so just mask it to 4 bits once we know its a GPR. llvm-svn: 333725
2018-06-01 13:12:44 +08:00
#CHECK: vcvtusi2sdq %rax, %xmm1, %xmm1
[X86] Add a test case showing a bad disassembling of an EVEX instruction with EVEX.X=0 and a GPR encoded in modrm.rm. EVEX.X is used to extended modrm.rm when the instruction encodes a XMM/YMM/ZMM register. But we aren't properly ignoring it when it encodes a GPR and we end up printing whatever registers exist in X86 register enum after the GPRs. llvm-svn: 333724
2018-06-01 13:12:43 +08:00
0x62 0xb1 0xf7 0x08 0x7b 0xc8
[X86][Disassembler] Ignore EVEX.X extension of modrm.rm to 5-bits when modrm.rm encodes a k-register. llvm-svn: 333727
2018-06-01 13:36:08 +08:00
# Make sure we ignore EVEX.X when modrm.rm encodes a k-register.
#CHECK: vpmovm2b %k0, %xmm0
0x62,0xb2,0x7e,0x08,0x28,0xc0
[X86] Teach disassembler to use %eip instead of %rip when 0x67 prefix is used on a rip-relative address. llvm-svn: 335413
2018-06-23 14:03:48 +08:00
# 0x67 prefix prints %eip instead of %rip
#CHECK: addb %al, (%eip)
0x67,0x00,0x05,0x00,0x00,0x00,0x00
[X86][Disassembler] Add bizarro versions of the MOVSXD instruction that sign extend from a GR32 to GR32 or GR16. The 0x63 opcodes in 64-bit mode have a fixed source size of 32-bits, but the destination size is controlled by REX.W and the 0x66 opsize prefix. This instruction is normally used with a REX.W prefix which provides desired behavior. The other encodings are interpretted as valid by the processor, but aren't useful. This patch makes us recognize them for the disassembler to match objdump. llvm-svn: 343614
2018-10-03 02:16:19 +08:00
# CHECK: movslq %eax, %eax
0x63 0xc0
# CHECK: movslq %eax, %ax
0x66 0x63 0xc0
# CHECK: movslq (%rax), %ecx
0x63 0x08
# CHECK: movslq (%rax), %cx
0x66 0x63 0x08