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

[Edward Nevill]

On Mon, 2015-12-07 at 14:20 +0000, Andrew Haley wrote:
> On 12/07/2015 12:22 PM, Edward Nevill wrote:
> 
> > I cannot see what prevents one of these BLs from being followed and
> > since they may have been copied but not relocated then they may end
> > up pointing somewhere random in the code buffer which just happens
> > to look like a trampoline. Admittedly, the probability of failure is
> > vastly reduced because there are no genuine trampolines for it to
> > latch on to.
> 
> You must look inside get_trampoline().  It checks for this.

OK. Thanks, I have satisfied myself that this is correct.

New webrev @ http://cr.openjdk.java.net/~enevill/8144498/webrev.2

I was having difficulty understanding why the check inside get_trapoline() did not exclude the adrp/add relocation. However when I trap it doing the relocation in gdb I see

Original:
   0x3ff54170b50:       adrp    x8, 0x3ff54170000  <<< Not in code blob
   0x3ff54170b54:       add     x8, x8, #0x400
   0x3ff54170b58:       blr     x8

Copied but not relocated.
   0x3ff5481d250:       adrp    x8, 0x3ff5481d000  <<< Within code blob
   0x3ff5481d254:       add     x8, x8, #0x400
   0x3ff5481d258:       blr     x8

So the destination offset in the original is 0x3ff54170400 - 0x3ff54170b50 = 0xfffffffffffff8b0, whereas in the copied but not relocated version it is 0x3ff5481d400 - 0x3ff5481d250 = 0x1b0 which is within the current code blob.

This happens because of the half PC relative, half absolute nature of the adrp/add relocation in that the bottom 12 bits are always absolute whereas the adrp instruction is PC relative.

I have retested this with JTreg hotspot & langtools with ReservedCodeCacheSize=256m

Hotspot original: Test results: passed: 865; failed: 19; error: 85
Hotspot revised: Test results: passed: 953; failed: 9; error: 12

Langtools original: Test results: passed: 3,049; failed: 77; error: 223
Langtools revised: Test results: passed: 3,316; failed: 33

Thanks for the review,
Ed.