In LIR_Assembler::klass2reg_with_patching we emit
48ba 0000 | 0000 0000 | 0000
^--------------------------^
movabs rdx, 0
then, let's say we add a jump after:
48ba 0000 | 0000 0000 | 0000 e983 | 0400 00
^--------------------------^ ^------------^
movabs rdx, 0 rel32 jmp
Later, in PatchingStub::emit_code we overwrite the movabs with a jump, and now, the binary looks like:
e983 0400 | 0000 0000 | 0000 e983 | 0400 00
^------------^^------------^ ^------------^
rel32 jmp leftover rel32 jmp
And later, the disassembler get confused:
jmp 0x00007f84d9000c38 ; the jump, correct
add BYTE PTR [rax],al ; 0000 trash
add BYTE PTR [rax],al ; 0000 trash
add cl,ch ; 00e9 trash, and shifted
add DWORD PTR [rax+rax*1],0x0 ; 8304 0000 misinterpreted jmp rel32
It may sync again, or lead to an invalid opcode.
But it's purely a debugging problem: since this trash 0s are after an unconditional jump (that used to be the middle of an instruction), nobody is going to execute them.
Using nop (0x90) payload could avoid that.
48ba 0000 | 0000 0000 | 0000
^--------------------------^
movabs rdx, 0
then, let's say we add a jump after:
48ba 0000 | 0000 0000 | 0000 e983 | 0400 00
^--------------------------^ ^------------^
movabs rdx, 0 rel32 jmp
Later, in PatchingStub::emit_code we overwrite the movabs with a jump, and now, the binary looks like:
e983 0400 | 0000 0000 | 0000 e983 | 0400 00
^------------^^------------^ ^------------^
rel32 jmp leftover rel32 jmp
And later, the disassembler get confused:
jmp 0x00007f84d9000c38 ; the jump, correct
add BYTE PTR [rax],al ; 0000 trash
add BYTE PTR [rax],al ; 0000 trash
add cl,ch ; 00e9 trash, and shifted
add DWORD PTR [rax+rax*1],0x0 ; 8304 0000 misinterpreted jmp rel32
It may sync again, or lead to an invalid opcode.
But it's purely a debugging problem: since this trash 0s are after an unconditional jump (that used to be the middle of an instruction), nobody is going to execute them.
Using nop (0x90) payload could avoid that.