Am Freitag, den 09.08.2019, 16:45 -0600 schrieb Jeff Law:
> On 6/24/19 3:35 PM, Uecker, Martin wrote:
> > 
> > 
> > Hi,
> > 
> > here is a new version of this patch. It makes "-fno-trampolines"
> > work for C which then makes it possible to use nested functions
> > without executable stack. The only change in this version is in
> > the documentation.
> > 
> > Maybe it could be reconsidered at this stage?
> > 
> > 
> > Bootstrapped and regression tested on x86.
> > 
> > Martin
> > 
> > 
> >     gcc/
> >             * common.opt (flag_trampolines): Change default.
> >             * calls.c (prepare_call_address): Remove check for
> >             flag_trampolines.  Decision is now made in FEs.
> >             * defaults.h (FUNCTION_ALIGNMENT): Add test for 
> > flag_trampolines.
> >             * tree-nested.c (convert_tramp_reference_op): Likewise.
> >             * toplev.c (process_options): Add warning for -fno-trampolines 
> > on
> >             unsupported targets.
> >             * doc/invoke.texi (-fno-trampolines): Document support for C.
> >     gcc/ada/
> >             * gcc-interface/trans.c (Attribute_to_gnu): Add check for
> >             flag_trampolines.
> >     gcc/c/
> >             * c-typeck.c (function_to_pointer_conversion): If using 
> > descriptors
> >             instead of trampolines, amend function address with
> >             FUNC_ADDR_BY_DESCRIPTOR and calls with ALL_EXPR_BY_DESCRIPTOR.
> >     gcc/testsuite/
> >             * gcc.dg/trampoline-2.c: New test.
> >             * lib/target-supports.exp
> >             (check_effective_target_notrampolines): New.
> 
> IIRC we got stuck last year on the requirement that there be some bit we
> can use to distinguish that we have a function descriptor which is an
> ABI change, even more so if we have to bump the function alignment
> requirements to give us a bit we can use.
> 
> Which in my experience means the option won't really be used.  You have
> to build the entire system with the new options and also ensure you
> aren't ever running old code that was compiled without the option.

A safe use case which does not require recompiling everything
is to use it to support localized use of nested functions, e.g.
code which uses nested functions locally but does not pass
or receive function pointers from/to library functions.

As this is the typical use case for nested functions this is
very useful to support them in cases where executable  stacks
are not an option.

The other thing to note is that the minimum function alignment
is usually always automatically high enough with optimization.

> I'm not really in favor of adding the option.  But I won't stand in the
> way if another maintainer wants to try and move forward with this.

The option already exists. It just does not work for
C which is surprising.

Best,
Martin

Reply via email to