archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <>
To: Segher Boessenkool <>
Cc: Borislav Petkov <>, X86 ML <>,
	Michael Matz <>,,
	LKML <>,
	Josh Poimboeuf <>
Subject: Re: [PATCH] x86/sev: Mark snp_abort() noreturn
Date: Thu, 25 Aug 2022 08:41:19 +0200	[thread overview]
Message-ID: <YwcZjxVkO/> (raw)
In-Reply-To: <>

On Wed, Aug 24, 2022 at 05:41:44PM -0500, Segher Boessenkool wrote:

> It is!  A noreturn function (that doesn't warn like "warning: 'noreturn'
> function does return") does not have whatever your architecture uses for
> function returns in it.  Just like most non-noreturn functions that do
> not return btw: the attribute affects code generation of the *caller* of
> such functions.

Yeah, but objtool can't tell if the compiler just spazzed out and
stopped generating code or if it was intentional.

> > STT_FUNC_NORETURN would do I suppose, except then all
> > the tools will need to be taught how to deal with that, which is also
> > very painful.
> What is that?  Even Google has no idea.  Hrm.

Something I just made up :-) A new symbol type for noreturn functions
would be very useful.

> What fundamental problem does objtool have in dealing with any normal
> compiled code itself?  Does it try to understand the semantics of the
> machine code (not very tractable), does it expect some magic markup to
> be generated together with the machine code, does it want to have
> compilers hamstrung wrt what kind of code they can generate?
> There is some serious disconnect here, and I'm not even completely sure
> what it is :-(

Objtool follows control flow. As you said above, noreturn functions
behave differently and code-gen after a call to a noreturn function

Typically objtool expects a call instruction to return and continue on
the next instruction; if all of a sudden there's nothing there, it gets
suspicious and says the compiler messed up.

(FWIW, we've found a fair number of actual compiler bugs with this)

Now, as mentioned we have heuristics that try and detect if a function
is noreturn or not; but all those fail horribly if the function is in
another translation unit for example.

  reply	other threads:[~2022-08-25  6:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-24 15:24 [PATCH] x86/sev: Mark snp_abort() noreturn Borislav Petkov
2022-08-24 15:38 ` Peter Zijlstra
2022-08-24 15:48   ` Borislav Petkov
2022-08-24 16:16     ` Peter Zijlstra
2022-08-24 16:43       ` [PATCH v2] " Borislav Petkov
2022-08-24 17:29 ` [PATCH] " Segher Boessenkool
2022-08-24 18:23   ` Borislav Petkov
2022-08-24 18:44   ` Nick Desaulniers
2022-08-24 19:43     ` Segher Boessenkool
2022-08-24 20:45   ` Peter Zijlstra
2022-08-24 22:41     ` Segher Boessenkool
2022-08-25  6:41       ` Peter Zijlstra [this message]
2022-08-25 12:29         ` Michael Matz
2022-08-25 12:58         ` Segher Boessenkool
2022-08-25 13:12         ` David Laight
2022-08-30  4:48           ` Josh Poimboeuf
2022-08-30  4:46     ` Josh Poimboeuf

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YwcZjxVkO/ \ \ \ \ \ \ \ \ \

* 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).