linux-toolchains.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jakub Jelinek <jakub@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-toolchains@vger.kernel.org, x86@kernel.org
Subject: Re: GCC 15 -fzero-init-padding-bits= option and redzone clobber
Date: Sat, 30 Nov 2024 05:10:40 -0600	[thread overview]
Message-ID: <20241130111040.GR29862@gate.crashing.org> (raw)
In-Reply-To: <CAHk-=wj=s8rPKi+ju+eadh0rVU76oZ1XwE3xUjwj9osM8Cea3A@mail.gmail.com>

Hi!

On Fri, Nov 29, 2024 at 10:21:13AM -0800, Linus Torvalds wrote:
> On Fri, 29 Nov 2024 at 09:55, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > This has happened with both gcc and clang, and telling the compiler
> > that we need the stack pointer fixes it. I don't actually remember who
> > told us to do that, but I think it was a gcc person.
> >
> > In fact, if I were a betting man, I would have thought it was you ;)
> 
> Ahh, found it. Not you. Segher. Doing some archeology finds this:
> 
>     https://gcc.gnu.org/legacy-ml/gcc/2015-07/msg00080.html
> 
> and even at the time, Segher suggested maybe having a separate "stack"
> clobber. But obviously that wasn't available at the time, and afaik
> has never happened.

But that would not mean changing the stack pointer, writing to something
on the stack instead.  Something like this "redzone" thing maybe.  I did
say it would have to have precise semantics specified :-)

> So we used that gcc suggestion, and it has worked fine for most of a
> decade by now.

Interesting.  And I was even accused of being "clever" in that thread,
wow!  :-)

But of course, GCC assumes there is a properly set up stack
*everywhere*, it can in principle insert calls *anywhere*.  So these
asm constraints are totally superfluous anyway!

(Input constraints do not say a reg is read, and output constraints do
not say it is written to.  Instead, they express the data flow,
something that is actually useful to the compiler, and very much
required as well).


Segher

  reply	other threads:[~2024-11-30 11:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-28 11:19 GCC 15 -fzero-init-padding-bits= option and redzone clobber Jakub Jelinek
2024-11-29 12:52 ` Peter Zijlstra
2024-11-29 13:23   ` Jakub Jelinek
2024-11-29 17:55     ` Linus Torvalds
2024-11-29 18:21       ` Linus Torvalds
2024-11-30 11:10         ` Segher Boessenkool [this message]
2024-11-30 17:43           ` Linus Torvalds
2024-11-30 22:19             ` Segher Boessenkool
2024-11-30 22:43               ` Linus Torvalds
2024-11-30 22:45                 ` Linus Torvalds

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=20241130111040.GR29862@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=jakub@redhat.com \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.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 NNTP newsgroup(s).