| Message ID | 20210525202318.17690-1-eggert@cs.ucla.edu |
|---|---|
| State | New |
| Headers | show |
| Series | Document that -fno-trampolines is for Ada only [PR100735] | expand |
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
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.
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
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
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
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