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

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

[Martin Uecker]

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

 

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

[Jeff Law]

On 6/9/2021 12:15 PM, Thomas Rodgers wrote:
>
> On 2021-06-09 09:23, Jeff Law via Gcc-patches 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.
>>
>> The patch is fine, I just wanted to give you a bit of background on 
>> the state.   I'll go ahead and commit it for you.
>>
>> Jeff
>>
> This patch (commit 4a0c4eaea32) is currently breaking the compilation 
> with "Verify that you have permission to grant a GFDL license for 
> all". It appears that tm.texi and tm.texi.in are out of sync.
>
My fault.  I applied the change to tm.texi by hand and mucked up a 
newline.    HJ fixed it for me, then I mucked up  again, then fixed it 
again...   I'll refrain for complaining about GDFL for everyone's sanity...

jeff

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

[H.J. Lu]

On Wed, Jun 9, 2021 at 11:15 AM Thomas Rodgers
<rodgert@appliantology.com> wrote:
>
> On 2021-06-09 09:23, Jeff Law via Gcc-patches 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.
> >
> > The patch is fine, I just wanted to give you a bit of background on the
> > state.   I'll go ahead and commit it for you.
> >
> > Jeff
>
> This patch (commit 4a0c4eaea32) is currently breaking the compilation
> with "Verify that you have permission to grant a GFDL license for all".
> It appears that tm.texi and tm.texi.in are out of sync.

I am checking in this to unbreak it:

diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 20501607716..33532f092b6 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -3828,6 +3828,7 @@ addresses.  Since GCC's generic function descriptors are
 not ABI-compliant, this option is typically used only on a
 per-language basis (notably by Ada) or when it can otherwise be
 applied to the whole program.
+
 For languages other than Ada, the @code{-ftrampolines} and
 @code{-fno-trampolines} options currently have no effect, and
 trampolines are always generated on platforms that need them

-- 
H.J.

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

[Iain Sandoe]

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

cheers
Iain

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

[Thomas Rodgers]

On 2021-06-09 09:23, Jeff Law via Gcc-patches 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.
> 
> The patch is fine, I just wanted to give you a bit of background on the 
> state.   I'll go ahead and commit it for you.
> 
> Jeff

This patch (commit 4a0c4eaea32) is currently breaking the compilation 
with "Verify that you have permission to grant a GFDL license for all". 
It appears that tm.texi and tm.texi.in are out of sync.

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

[Jeff Law]

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.

The patch is fine, I just wanted to give you a bit of background on the 
state.   I'll go ahead and commit it for you.

Jeff

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

[Paul Eggert]

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.
---
 gcc/doc/invoke.texi | 5 +++++
 gcc/doc/tm.texi.in  | 4 ++++
 2 files changed, 9 insertions(+)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 5cd4e2d993c..b55bbf3e424 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -16646,6 +16646,11 @@ Moreover, code compiled with @option{-ftrampolines} and code compiled with
 present.  This option must therefore be used on a program-wide basis and be
 manipulated with extreme care.
 
+For languages other than Ada, the @code{-ftrampolines} and
+@code{-fno-trampolines} options currently have no effect, and
+trampolines are always generated on platforms that need them
+for nested functions.
+
 @item -fvisibility=@r{[}default@r{|}internal@r{|}hidden@r{|}protected@r{]}
 @opindex fvisibility
 Set the default ELF image symbol visibility to the specified option---all
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index d9fbbe20e6f..20501607716 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -3828,6 +3828,10 @@ addresses.  Since GCC's generic function descriptors are
 not ABI-compliant, this option is typically used only on a
 per-language basis (notably by Ada) or when it can otherwise be
 applied to the whole program.
+For languages other than Ada, the @code{-ftrampolines} and
+@code{-fno-trampolines} options currently have no effect, and
+trampolines are always generated on platforms that need them
+for nested functions.
 
 Define the following hook if your backend either implements ABI-specified
 descriptor support, or can use GCC's generic descriptor implementation
-- 
2.31.1