public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Joseph Myers <joseph@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] PR880088 Enable -Wtrampolines for no-exec-stack targets with -Wall.
Date: Mon, 26 Nov 2018 19:23:00 -0000	[thread overview]
Message-ID: <f49a6a3b1fb65492902c0f3596319b2f1b194200.camel@klomp.org> (raw)
In-Reply-To: <alpine.DEB.2.21.1811261827140.30345@digraph.polyomino.org.uk>

On Mon, 2018-11-26 at 18:29 +0000, Joseph Myers wrote:
> On Mon, 26 Nov 2018, Mark Wielaard wrote:
> 
> > Define a new target macro TARGET_HAS_DEFAULT_NOEXEC_STACK for those
> > targets
> > that have a non-executable default stack based on when they call
> > file_end_indicate_exec_stack.
> 
> Some targets (e.g. ia64) may default to no-exec stacks without
> needing 
> that hook (e.g. if they use function descriptors, so trampolines have
> no 
> need for an executable stack).

Yes, but for such targets it doesn't really matter whether or not they
define this new target macro. The -Wtrampolines warning only warns when
creating an executable runtime trampoline on the stack. It won't for
non-executable trampolines. So yes, then this target macro doesn't have
to be defined even if the stack is non-executable by default. Defining
the TARGET_HAS_DEFAULT_NOEXEC_STACK macro for such a target will then
make it so that -Wall enables -Wtrampolines by default, but
-Wtrampolines still won't warn because the trampolines aren't
executable code on the stack. But I believe that is the correct
behavior. The warning should only happen if gcc would otherwise
silently make the stack executable for a target that has a default non-
executable stack (and it won't for target that uses function
descriptors).

I thought the documentation updates for the warning made that more
clear, but maybe they can be improved even more?

A case could be made that taking a nested function pointer that escapes
the lexical scope from which it takes some context variable always is a
dangerous thing to do and that it should even warn if supporting that
doesn't involve placing an executable runtime trampoline on the stack.
Which is actually the case I made in the original bug. But I don't
believe I got consensus for that.

Thanks,

Mark

  reply	other threads:[~2018-11-26 19:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-26  9:13 Mark Wielaard
2018-11-26 13:19 ` Paul Koning
2018-11-26 14:36   ` Mark Wielaard
2018-11-26 18:29 ` Joseph Myers
2018-11-26 19:23   ` Mark Wielaard [this message]
2018-11-27 18:37 ` Segher Boessenkool
2018-11-27 19:54   ` Mark Wielaard
2018-11-28 21:01     ` Segher Boessenkool
2018-11-29 11:57       ` Mark Wielaard
2018-11-29 16:41         ` Segher Boessenkool

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=f49a6a3b1fb65492902c0f3596319b2f1b194200.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    /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).