[aarch64-port-dev ] RFR: 8144498: aarch64: large code cache generates SEGV

Andrew Haley aph at redhat.com
Fri Dec 4 17:38:19 UTC 2015


On 12/04/2015 04:14 PM, Andrew Haley wrote:
> Your fix looks OK.

Scratch that, I'm seeing NetBeans failures with your patch.  I think
it's because you're missing a trampoline destination when the initial
relocation is being done.  This is because get_trampoline() looks for
a trampoline_stub reloc based on orig_addr, and this can never work.

(When a trampoline call is first created it is a call to self; the
reloc is the only way to find the trampoline.  For this reason, you
must use nativeCall_at(addr())->get_trampoline().)

I'm going to suggest this as a simpler fix:

address Relocation::pd_call_destination(address orig_addr) {
  assert(is_call(), "should be a call here");
  if (NativeCall::is_call_at(addr())) {  // is a BL instruction
    address trampoline = nativeCall_at(addr())->get_trampoline();
    if (trampoline) {
      return nativeCallTrampolineStub_at(trampoline)->destination();
    }
  }
  if (orig_addr != NULL) {
    return MacroAssembler::pd_call_destination(orig_addr);
  }
  return MacroAssembler::pd_call_destination(addr());
}

I think it's right because this way we only follow real BL
instructions, and if these point to trampolines they must be within
the blob which is being relocated.  I think this will fix your problem
because such BL instructions cannot point to anywhere wild.

Thanks,

Andrew.



More information about the aarch64-port-dev mailing list