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

[Andrew Haley]

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.

> Second, I am not such that your assertion
> 
>> (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().)
> 
> is correct. In MacroAssembler::trampoline_call I see
> 
>   if (Assembler::reachable_from_branch_at(pc(), entry.target())) {
>     bl(entry.target());
>   } else {
>     bl(pc());
>   }
> 
> so it only creates a call to self if the branch does not reach and
> as before you could have a dangling BL when this is copied.

It doesn't matter, because get_trampoline() checks for BLs outside
the  current method.

> I believe it would be possible to replace the above code section
> with simply
>
>   bl(pc());

> since it will always be relocated and therefore you can always
> generate the call to self.

True.  There are some other tidy-ups which could also be made in this
area, but none of it is terribly important as far as I can see.

> Maybe we could just get rid of trampolines?

There's no need.  In the commonest case we BL directly to the
destination, which is optimal.  Your ADRP/ADD examples aren't
patchable; if you are going to compare trampolines with something
else, whatever else you choose must be patchable, and it will be
slower and/or larger than BL.

Andrew.