C1: in x86, avoid 0x00s leftover after PatchingStub

XMLWordPrintable

    • Type: Enhancement
    • Resolution: Unresolved
    • Priority: P4
    • tbd
    • Affects Version/s: None
    • Component/s: hotspot

      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.

            Assignee:
            Marc Chevalier
            Reporter:
            Marc Chevalier
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: