[aarch64-port-dev ] Help debugging problem with large code cache

[Edward Nevill]

On Wed, 2015-12-02 at 14:24 +0000, Edward Nevill wrote:
> So it looks like the adrp is either not being relocated, or is being relocated incorrectly.
> 
> Any suggestions as to why it might be doing this??? I have had a long look at the pd_patch_* code and it seems correct to me.

I think I have it on the run!

I believe the following code is getting a false positive

inline bool is_NativeCallTrampolineStub_at(address addr) {
  // Ensure that the stub is exactly
  //      ldr   xscratch1, L
  //      br    xscratch1
  // L:
  uint32_t *i = (uint32_t *)addr;
  return i[0] == 0x58000048 && i[1] == 0xd61f0100;
}


when called from the following in get_trampoline()

  address bl_destination
    = MacroAssembler::pd_call_destination(call_addr);
  if (code->content_contains(bl_destination) &&
      is_NativeCallTrampolineStub_at(bl_destination))
    return bl_destination;

which in turn is called from the following in pd_call_destination

  if (is_call()) {  
    address trampoline = nativeCall_at(addr())->get_trampoline();
    if (trampoline) {
      return nativeCallTrampolineStub_at(trampoline)->destination();
    }
  }

so the call destination for overflow_counter is matched as a false positive and the destination of a trampoline is returned instead, so the adrp is relocated to this.

Should the following line

    address trampoline = nativeCall_at(addr())->get_trampoline();

be

    address trampoline = nativeCall_at(orig_addr)->get_trampoline();

IE the address before relocation. Because if the code has not been relocated yet, then the adrp could be pointing somewhere randomly within the code buffer, and it just happens sometimes to point to a valid trampoline stub.

Regards,
Ed