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: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Andy Lutomirski <luto@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Bill Wendling <morbo@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, Nathan Chancellor <nathan@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"llvm@lists.linux.dev" <llvm@lists.linux.dev>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-toolchains <linux-toolchains@vger.kernel.org>
Subject: Re: [PATCH v5] x86: use builtins to read eflags
Date: Fri, 18 Mar 2022 18:42:12 -0500	[thread overview]
Message-ID: <20220318234212.GU614@gate.crashing.org> (raw)
In-Reply-To: <CAHk-=wgKBme-SdbkSxbQ4+c6tZdvY2fe1wP1TgJeuDAf+AgwMg@mail.gmail.com>

On Fri, Mar 18, 2022 at 04:10:55PM -0700, Linus Torvalds wrote:
> It would be lovely to have some explicit model for "I want the frame
> to have been set up for backtraces", but here we are.

So please define exactly what that *means*?  Preferably portably, but I
reckon at least some of it will have to be machine-specific (and ABI-
specific).  But it needs to be well-defined, clearly defined, defined at
all, and *documented* :-)

> Marking '%rsp
> used makes the compiler understand it's not a leaf function.

As I said before, this is explicitly incorrect code.  Always was, but
it is documented since a while (since GCC 9).  Clobbering the stack
pointer can never be correct, the stack pointer after an asm has to be
identical to the one before that asm!

> And while we have other uses for it that then use the actual value,
> those don't care about the exact value of the stack pointer register,
> they just want "give me a pointer that is contained within the current
> stack", because we control the stack allocation and do funky things
> there. So "any random stack pointer value in this function" is
> perfectly fine and expected.

You can use %rsp as *input* operand just fine, which is all you need for
that.

> But for user mode, it would probably be a great idea to also have a "I
> cannot use a redzone in this function" thing. The kernel can't use it
> because we have nested exceptions, but maybe some day even the kernel
> could make use of (controlled) red-zoning.

Yes.  We just have to figure out what the exact semantics we want is,
and how to express that in a target-independent way, and then relatedly
what a good name for it would be ("redzone" in the clobber list is the
best I can come up with right now, but that may have to change).


Segher

  reply	other threads:[~2022-03-18 23:48 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220210223134.233757-1-morbo@google.com>
     [not found] ` <20220301201903.4113977-1-morbo@google.com>
     [not found]   ` <CAGG=3QWh90r5C3gmTj9zxiJb-mwD=PGqGwZZTjAfyi1NCb1_9w@mail.gmail.com>
     [not found]     ` <AC3D873E-A28B-41F1-8BF4-2F6F37BCEEB4@zytor.com>
     [not found]       ` <CAGG=3QVu5QjQK8m2FWiYn-XQuVBjUGXcbznSbK22jVMB5GAutw@mail.gmail.com>
     [not found]         ` <F5296439-4CA3-4F31-BD91-5ED1510BC382@zytor.com>
2022-03-17 18:00           ` [PATCH v5] x86: use builtins to read eflags Nick Desaulniers
2022-03-17 18:52             ` Linus Torvalds
2022-03-17 19:45               ` Bill Wendling
2022-03-17 20:13                 ` Linus Torvalds
2022-03-17 21:10                   ` Bill Wendling
2022-03-17 21:21                     ` Linus Torvalds
2022-03-17 21:45                       ` Bill Wendling
2022-03-17 22:51                         ` Linus Torvalds
2022-03-17 23:14                           ` Linus Torvalds
2022-03-17 23:19                           ` Segher Boessenkool
2022-03-17 23:31                             ` Linus Torvalds
2022-03-18  0:05                               ` Segher Boessenkool
2022-03-17 22:37                 ` Segher Boessenkool
2022-03-17 20:13               ` Florian Weimer
2022-03-17 20:36                 ` Linus Torvalds
2022-03-18  0:25                   ` Segher Boessenkool
2022-03-18  1:21                     ` Linus Torvalds
2022-03-18  1:50                       ` Linus Torvalds
2022-03-17 21:05               ` Andrew Cooper
2022-03-17 21:39                 ` Linus Torvalds
2022-03-18 17:59                   ` Andy Lutomirski
2022-03-18 18:19                     ` Linus Torvalds
2022-03-18 21:48                       ` Andrew Cooper
2022-03-18 23:10                         ` Linus Torvalds
2022-03-18 23:42                           ` Segher Boessenkool [this message]
2022-03-19  1:13                             ` Linus Torvalds
2022-03-19 23:15                             ` Andy Lutomirski
2022-03-18 22:09                       ` Segher Boessenkool
2022-03-18 22:33                         ` H. Peter Anvin
2022-03-18 22:36                         ` David Laight
2022-03-18 22:47                           ` H. Peter Anvin
2022-03-18 22:43                       ` David Laight
2022-03-18 23:03                         ` H. Peter Anvin
2022-03-18 23:04                   ` Segher Boessenkool
2022-03-18 23:52                     ` David Laight

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=20220318234212.GU614@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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).