diff options
author | Vedant Kumar <vsk@apple.com> | 2015-08-26 16:20:29 +0000 |
---|---|---|
committer | Vedant Kumar <vsk@apple.com> | 2015-08-26 16:20:29 +0000 |
commit | bf891b12b4a8fe0e64f89101e1d4ff451de923ec (patch) | |
tree | 26a34c726d316b2ba26d59e4925d69621f92e45b /clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.cpp | |
parent | f8ec454f7d3c1c8aa42eb6dc33784e3addfe1d58 (diff) | |
download | bcm5719-llvm-bf891b12b4a8fe0e64f89101e1d4ff451de923ec.tar.gz bcm5719-llvm-bf891b12b4a8fe0e64f89101e1d4ff451de923ec.zip |
[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
Diffstat (limited to 'clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.cpp')
0 files changed, 0 insertions, 0 deletions