This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v6][C][ADA] use function descriptors instead of trampolines in C


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.

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.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]