[Bug middle-end/29231] need a way to produce trampolines not on the stack

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29231

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=113401

--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
Current status.

We have implemented (currently for hosted x86 and aarch64) a heap-based
trampoline approach.

for efficiency heap trampolines are allocated in tables of one page in size (no
pages are allocated until the first trampoline requires one).  Pages are added
and subtracted as the number of trampoline tables increases/decreases.  One
proviso - the first allocated page is sticky (this avoids mmap/etc. churn if
there are a lot of single trampolines required).  Trampoline pages are per
thread.

The mechanism works with platforms that will not allow heap pages to be both
writable and executable at the same time (the page is made temporarily r+w to
make changes and then r+x for operation).  For Darwin, there's a permission
mode "jit" that does something similar.

A new platform needs to supply the libgcc support for example : 

libgcc/config/aarch64/heap-trampoline.c
libgcc/config/aarch64/t-heap-trampoline + a reference to this in
libgcc/config.host

A new platform can elect to default to heap trampolines by adding
HEAP_TRAMPOLINES_INIT=1 to tm_defines in the relevant target section in
gcc/config.gcc

There is currently (pre gcc-14 branch) one unhandled issue which is
reallocation of the last "sticky" trampoline page when a thread exits.

I would say, that (within realistic implementation constraints) we could count
this as fixed.

-- 
You are receiving this mail because:
You reported the bug.