On Sun, Jul 16, 2023 at 12:39 PM FX Coudert via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > Hi, > > This is a reworked version (following review) of the patch by Maxim Blinov > and Iain Sandoe enabling heap-based trampolines. What has changed since the > last version: > > - wording changes, preferring to use “heap-based trampolines” rather than > “off-stack trampolines” > - the option triggering generation of these new trampolines is now a binary > choice: -ftrampoline-impl=[stack|heap] > - some adjustments due to changes in the macOS build flags in GCC since last > year > > Regarding testing, this patch has had excellent exposure on darwin (both > x86_64 and aarch64) because it was part of Iain’s branch, distributed by many > macOS distros/vendors (including Homebrew) for more than a year, and there > was no bug report against the feature or implementation. On x86_64-linux, I > have regression-tested it in three different configurations: > - a default build > - a build with --enable-heap-trampolines > - a build with --enable-heap-trampolines and heap trampolines forced by > default (forcing HEAP_TRAMPOLINES_INIT = 1) > > There are no regressions in any of these settings (apart from an expected > missing warning in gcc.dg/Wtrampolines.c). > > ---------- > > From the original review, one question asked (by Jeff Law) was: whether the > two linux implementations should be dropped, and the configure time > selectability as well. Regardless of the answer to the first question, I > think we probably want to retain the later, even if only for darwin, as we > want to implement this only on recent darwin versions.
Since this affects the ABI of libgcc I think we don't want that part to be user configurable but rather determined by some static list of targets that opt-in to this config. You mention setjmp/longjmp - on darwin and other platforms requiring non-stack based trampolines does the system runtime provide means to deal with this issue like an alternate allocation method or a way to register cleanup? Was there ever an attempt to provide a "generic" trampoline driven by a more complex descriptor? (well, it could be a bytecode interpreter and the trampoline being bytecode on the stack?!) Otherwise I suggest to split the patch into libgcc, generic and target parts. Thanks, Richard. > > OK to commit? > > FX > >
