Assembly decode for x64 JMP instruction

Question

I am a very occasional user of assembly. So I need help from someone more expert to decode a small piece of code I have to deal with.

0000:  48 ff 25 61 57 07 00    rex.W jmp QWORD PTR [rip+0x75761]        # 0x75768
0007:  cc                      int3

This is a memory-indirect jump to an 8-byte/64-bit address held at rip+0x75761 , so the absolute address the jump target is loaded from is 0007 + 0x75761 = 0x75768 , right?

Answer 1

This is a standard tail-call sequence on x86-64, as would be generated by the Microsoft compiler.

Yes, as you said, it is an indirect jump to a 64-bit memory address, 0x75768 . At the point that this code is executed, rip is equal to 7, so rip + 0x75761 == 0x7 + 0x75761 == 0x75768 . The code will unconditionally transfer control to the instructions at the address 0x75768 .

The subsequent int 3 is just padding, but it also serves as a brick wall. Execution should never reach this point because of the unconditional branch in the previous instruction. If it did, the CPU would trap, since this is the "break" interrupt.

As for the REX.W prefix, harold is technically correct that it is unnecessary, but not for the reason you might think. Somewhat surprisingly, when an indirect jump through a register is used on x86-64, Windows requires the REX.W prefix in order to ensure that stack unwinding is successful. The stack unwinding code uses this as a signal internally. Ross Ridge has written an excellent answer about the purpose of REX-prefixed JMP instructions in Windows x64.

It is not strictly necessary in this case because this is an indirect jump with an IP-relative operand, but the compiler is apparently emitting it anyway. Its logic for handling this is probably not that complex, and perhaps it always generates this code for consistency. Or maybe the official documentation is not comprehensive on exactly how the stack unwinding code is implemented. Better safe than sorry, since there's no real disadvantage in an extra REX.W prefix.