Constant trampoline pages

Constant trampoline pages

[Richard Henderson]

The current iOS support to have a page of allocated trampolines that gets
remapped as needed, rather than writing and flushing them, makes me wonder if
we shouldn't do the same thing for *all* targets.

Years ago I wrote a small library to demonstrate this on Linux.  The idea was
to be able to use these trampolines for nested functions within gcc.  That
never went anywhere because people were more interested in avoiding trampolines
entirely than making them work better.

But for libffi it could work better than our current workarounds for selinux.

The source for my trampoline library can be found at

  git://github.com/rth7680/tramp.git

Possibly the most interesting part is the tramp-raw.c file, where I map back
from an address in virtual memory back to a filename + file offset.   At least
for elf hosts with dl_iterate_phdr, which is Linux plus recent BSDs afaik.

Thoughts?


r~

Re: Constant trampoline pages

[Andrew Haley]

On 23/01/15 17:54, Richard Henderson wrote:
> 
> Thoughts?

It looks a lot better than what we have now.  I don't quite get how a
single page of allocated trampolines can suffice, though, even after
reading the code.

The big problem we've had with the dual-mapping trick was how to
survive a fork().  I wonder if your scheme could help with that.

Andrew.

Re: Constant trampoline pages

[Richard Henderson]

On 01/26/2015 02:01 AM, Andrew Haley wrote:
> It looks a lot better than what we have now.  I don't quite get how a
> single page of allocated trampolines can suffice, though, even after
> reading the code.

Huh?  That's why tramp-raw.c is able to re-map the trampoline page
multiple times.

After that you've got a normal sort of fixed-size object heap allocation
problem.  One example is in the tramp-heap.c file, but there are others.


r~