public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/29231] need a way to produce trampolines not on the stack Date: Thu, 04 Apr 2024 08:25:09 +0000 [thread overview] Message-ID: <bug-29231-4-hie4X2awZW@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-29231-4@http.gcc.gnu.org/bugzilla/> 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.
next prev parent reply other threads:[~2024-04-04 8:25 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-29231-4@http.gcc.gnu.org/bugzilla/> 2021-11-28 0:02 ` pinskia at gcc dot gnu.org 2024-04-03 23:24 ` pinskia at gcc dot gnu.org 2024-04-04 8:25 ` iains at gcc dot gnu.org [this message] 2024-04-04 10:36 ` iains at gcc dot gnu.org 2006-09-25 23:21 [Bug target/29231] New: powerpc libgcc writes code to " debian-gcc at lists dot debian dot org 2006-09-25 23:53 ` [Bug middle-end/29231] need a way to produce trampolines not on " pinskia at gcc dot gnu dot org 2006-09-26 0:44 ` geoffk at gcc dot gnu dot org 2006-09-26 4:06 ` acahalan at gmail dot com 2009-01-01 21:25 ` pinskia at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-29231-4-hie4X2awZW@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).