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

[Martin Uecker via Gcc-patches]

> 
> 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).
> 

For reference the discussion and PATCH for C can be found here:

https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg01532.html


FWIW: There is a proposal discussed in WG14 to add lambdas.

In this context a more general and portable solution to this
problem would also be useful. 

One related idea is to add a wider function pointer type
to C that includes a data pointer.  A regular function
pointer could be converted to the wider pointer but
back conversion only works if it originally was a
regular function pointer.  This pointer type could then
also be used for interoperablity with other languages
that have callable objects or closures.

If GCC could add something like this and there is then
implementation experience, we could later try to
standardize it. (there was also positive feedback
to this idea from some C++ people I spoke to)


Martin