Re: GCC 15 -fzero-init-padding-bits= option and redzone clobber

Linus Torvalds <[email protected]>
Newsgroups org.kernel.vger.linux-toolchains
Message-ID <CAHk-=whJvN-pNfze=iher7nf1gkbA3DJ6+tPdCvVQVdBsdQEZQ@mail.gmail.com>
On Sat, 30 Nov 2024 at 03:13, Segher Boessenkool
<[email protected]> wrote:
>
> 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!

Well, I wish that were true. But we used your trick for a reason: it
fixed a real and present issue.

So no. It's not superfluous. It's required.

Without that "add sp register as a a input/output reg", at least some
versions of gcc did in fact put inline asm in places where the frame
was not set up.

You seem to imply that that may be a gcc bug, of course. Par for the
course - we have had other odd things in inline asms (or around them)
for other gcc bugs.

We do have commentary in some of our commits to that "it's a gcc bug"
effect, ie this commit message from "only" seven years ago states:

    With GCC 7.2, however, GCC's behavior has changed.  It now changes its
    behavior based on the conversion of the register variable to a global.
    That somehow convinces it to *always* set up the frame pointer before
    inserting *any* inline asm.  (Therefore, listing the variable as an
    output constraint is a no-op and is no longer necessary.)

So if it makes you feel any better, the trick now works for a
_different_reason_. Just the existence of the global register variable
seems to matter to those newer versions of gcc.

But we technically still support those older gcc versions that require
the old format (we still support back to gcc-5.1, although IO think
we're about to make the jump up to 8.1 based on staid enterprise
distro people finally having left some of the ancient stuff behind).

So we *may* be able to remove this hack, if gcc people can actually
pinky promise that it's not required with anything newer than 8.1

          Linus
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.