{"push_id":771089942,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"33dc79fffce2192b1bdb7f962c61414924829924","before":"97e8a915188df63109ea51ee9c131ed9c29e2f4f","commits":[{"sha":"33dc79fffce2192b1bdb7f962c61414924829924","author":{"email":"004c457a2ebaecf18123fd2614baa1d571fe5234@apple.com","name":"Vedant Kumar"},"message":"[llvm-mc] Ignore opcode size prefix in 64-bit CALL disassembly\n\nThis is a fix for disassembling unusual instruction sequences in 64-bit\nmode w.r.t the CALL rel16 instruction. It might be desirable to move the\ncheck somewhere else, but it essentially mimics the special case\nhandling with JCXZ in 16-bit mode.\n\nThe current behavior accepts the opcode size prefix and causes the\ncall's immediate to stop disassembling after 2 bytes. When debugging\nsequences of instructions with this pattern, the disassembler output\nbecomes extremely unreliable and essentially useless (if you jump midway\ninto what lldb thinks is a unified instruction, you'll lose %rip). So we\nignore the prefix and consume all 4 bytes when disassembling a 64-bit\nmode binary.\n\nNote: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S.\nis defined as:\n\n    Indicates an instruction syntax that requires an address override\n    prefix in 64-bit mode and is not supported. Using an address\n    override prefix in 64-bit mode may result in model-specific\n    execution behavior. (Vol. 2A 3-7)\n\nSince 0x66 is an operand override prefix we should be OK (although we\nmay want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested\nwith, they all ignore the 0x66 prefix in 64-bit mode.\n\nPatch by Matthew Barney!\n\nDifferential Revision: http://reviews.llvm.org/D9573","distinct":true,"url":"https://api.github.com/repos/llvm-project/llvm-project/commits/33dc79fffce2192b1bdb7f962c61414924829924"}]}