[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