[PATCH] Document that -fno-trampolines is for Ada only [PR100735]

Iain Sandoe idsandoe@googlemail.com
Wed Jun 9 18:38:39 GMT 2021

Jeff et. al.

> On 9 Jun 2021, at 17:23, Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> On 5/25/2021 2:23 PM, Paul Eggert wrote:
>> The GCC manual's documentation of -fno-trampolines was apparently
>> written from an Ada point of view. However, when I read it I
>> understandably mistook it to say that -fno-trampolines also works for
>> C, C++, etc. It doesn't: it is silently ignored for these languages,
>> and I assume for any language other than Ada.
>> This confusion caused me to go in the wrong direction in a Gnulib
>> dicussion, as I mistakenly thought that entire C apps with nested
>> functions could be compiled with -fno-trampolines and then use nested
>> C functions in stack overflow handlers where the alternate stack
>> is allocated via malloc. I was wrong, as this won't work on common
>> platforms like x86-64 where malloc yields non-executable storage.
>> gcc/
>> * doc/invoke.texi (Code Gen Options):
>> * doc/tm.texi.in (Trampolines):
>> Document that -fno-trampolines and -ftrampolines work
>> only with Ada.
> So Martin Uecker probably has the most state on this.  IIRC when we last discussed -fno-trampolines the belief was that it could be easily made to work independent of the language, but that it was ultimately an ABI change.   That ultimately derailed plans to use -fno-trampolines for other languages in the immediate term.

This is correct, it’s not technically too hard to make it work for another language (I have a hack in my arm64-darwin branch that does this for gfortran).  As noted for most ports it is an ABI break and thus not usable outside a such a work-around.

For the record (for the arm64-darwin port in the first instance), together with some of my friends at embecosm we plan to implement a solution to the trampoline that does not require executable stack and does not require an ABI break.  Perhaps such a solution will be of interest to other ports that do not want executable stack.

We’re not quite ready to post the design yet - but will do so in the next few weeks (all being well).


More information about the Gcc-patches mailing list