public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Andreas Schwab <schwab@suse.de>
Cc: Siddhesh Poyarekar <siddhesh@gotplt.org>,
	Martin Uecker <ma.uecker@gmail.com>,
	polacek@redhat.com, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] gcc: Disallow trampolines when -fhardened
Date: Mon, 4 Dec 2023 17:45:14 +0100	[thread overview]
Message-ID: <ZW4CGoIOnSKsrwoy@tucnak> (raw)
In-Reply-To: <mvmttox9b2v.fsf@suse.de>

On Mon, Dec 04, 2023 at 05:39:04PM +0100, Andreas Schwab wrote:
> On Dez 04 2023, Siddhesh Poyarekar wrote:
> 
> > For hardened code in C, I think we really should look to step away from
> > nested functions instead of adding ways to continue supporting it. There's
> > probably a larger conversation to be had about the utility of nested
> > functions in general for C (and whether this GCC extension should be
> > deprecated altogether in future), but I feel like the -fhardened subset
> > gives us the opportunity to enforce at least a safe subset for now,
> > possibly extending it in future.
> 
> Nested functions by itself don't need a trampoline, only if the address
> of it is passed outside the containing function's scope (as a callback,
> for example).

And only if the code to which it is passed can't be inlined back.

I'm afraid contained functions in Fortran or in Ada (whatever it is called
there) aren't going away any time soon and having the possibility to test it
also in C and not just Fortran/Ada is very useful at least from compiler
testing POV.

	Jakub


  reply	other threads:[~2023-12-04 16:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-01 19:33 Marek Polacek
2023-12-01 19:44 ` Andrew Pinski
2023-12-01 20:53   ` Marek Polacek
2023-12-01 21:14     ` Jakub Jelinek
2023-12-07 15:34     ` Eric Botcazou
2023-12-02  9:42 ` Martin Uecker
2023-12-02 10:24   ` Iain Sandoe
2023-12-04 16:26   ` Siddhesh Poyarekar
2023-12-04 16:39     ` Andreas Schwab
2023-12-04 16:45       ` Jakub Jelinek [this message]
2023-12-04 16:46       ` Siddhesh Poyarekar
2023-12-04 17:21         ` Martin Uecker
2023-12-04 18:27           ` [gcc15] nested functions in C Siddhesh Poyarekar
2023-12-04 18:48             ` Martin Uecker
2023-12-04 20:35               ` Siddhesh Poyarekar
2023-12-04 21:31                 ` Martin Uecker
2023-12-05 12:32                   ` Siddhesh Poyarekar
2023-12-04 21:33                 ` Joseph Myers
2023-12-04 22:31                   ` Martin Uecker
2023-12-05 21:08                     ` Joseph Myers
2023-12-05 21:15                       ` Martin Uecker
2023-12-06  7:39                         ` Richard Biener
2023-12-04 18:51             ` Jakub Jelinek
2023-12-04 19:13               ` Martin Uecker
2023-12-04 20:15               ` Siddhesh Poyarekar
2023-12-07 15:42                 ` Eric Botcazou
2023-12-07 15:50                   ` Siddhesh Poyarekar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZW4CGoIOnSKsrwoy@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ma.uecker@gmail.com \
    --cc=polacek@redhat.com \
    --cc=schwab@suse.de \
    --cc=siddhesh@gotplt.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).