From: Segher Boessenkool <segher@kernel.crashing.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>,
kbuild-all@lists.01.org,
clang-built-linux <clang-built-linux@googlegroups.com>,
linux-toolchains@vger.kernel.org,
kernel test robot <lkp@intel.com>,
Arvind Sankar <nivedita@alum.mit.edu>,
Ard Biesheuvel <ardb@kernel.org>,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Subject: Re: [RFC][PATCH 21/24] x86/entry: Disable stack-protector for IST entry C handlers
Date: Fri, 13 Nov 2020 17:47:01 -0600 [thread overview]
Message-ID: <20201113234701.GV2672@gate.crashing.org> (raw)
In-Reply-To: <CAKwvOdnvhyNs1arkVO1=pw9GB9NePKUfQYAY+Q0Ur9Qe9HJ37w@mail.gmail.com>
Hi!
On Fri, Nov 13, 2020 at 10:59:26AM -0800, Nick Desaulniers wrote:
> The `optimize` attribute is both non-portable across toolchains (hence
> this warning)
Like *all* GCC extensions.
> and a little quirky in GCC.
How so? Don't spread FUD please, say what *is* wrong, then people can
decide for themselves whether they want it or not.
We (GCC) do document it as:
Not every optimization option that starts with the -f prefix
specified by the attribute necessarily has an effect on the
function. The 'optimize' attribute should be used for debugging
purposes only. It is not suitable in production code.
The optimize attribute is for setting/resetting flags on a function
granularity. Not all flags can be flipped per function. The SSP flags
work fine though, AFAIK. But don't use it for production, there are no
guarantees.
Cheers,
Segher
next prev parent reply other threads:[~2020-11-13 23:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20201109144425.270789-22-alexandre.chartre@oracle.com>
[not found] ` <202011131552.4kvOb9Id-lkp@intel.com>
2020-11-13 18:59 ` [RFC][PATCH 21/24] x86/entry: Disable stack-protector for IST entry C handlers Nick Desaulniers
2020-11-13 19:39 ` Alexandre Chartre
2020-11-13 19:45 ` Nick Desaulniers
2020-11-13 23:47 ` Segher Boessenkool [this message]
2020-11-14 0:01 ` Miguel Ojeda
2020-11-14 0:26 ` Segher Boessenkool
2020-11-14 1:58 ` Miguel Ojeda
2020-11-14 10:20 ` Ard Biesheuvel
2020-11-25 19:56 ` Kees Cook
2020-11-25 23:00 ` Segher Boessenkool
2020-11-26 6:40 ` Ard Biesheuvel
2020-11-26 20:22 ` Segher Boessenkool
2020-11-26 21:05 ` Arvind Sankar
2020-11-26 22:00 ` Ard Biesheuvel
2020-11-14 0:11 ` Nick Desaulniers
2020-11-14 0:43 ` Segher Boessenkool
2020-11-14 0:48 ` Nick Desaulniers
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=20201113234701.GV2672@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=alexandre.chartre@oracle.com \
--cc=ardb@kernel.org \
--cc=clang-built-linux@googlegroups.com \
--cc=kbuild-all@lists.01.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=lkp@intel.com \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=ndesaulniers@google.com \
--cc=nivedita@alum.mit.edu \
/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 NNTP newsgroup(s).