Re: [PATCH] x86/sev: Mark snp_abort() noreturn

From: Michael Matz <matz@suse.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
	Borislav Petkov <bp@alien8.de>, X86 ML <x86@kernel.org>,
	linux-toolchains@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [PATCH] x86/sev: Mark snp_abort() noreturn
Date: Thu, 25 Aug 2022 12:29:38 +0000 (UTC)	[thread overview]
Message-ID: <alpine.LSU.2.20.2208251219590.24312@wotan.suse.de> (raw)
In-Reply-To: <YwcZjxVkO/lspvmv@worktop.programming.kicks-ass.net>

Hello,

On Thu, 25 Aug 2022, Peter Zijlstra wrote:

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

But very, very, very painful for everyone else :-)  And: there are only 15 
symbol types, and in the OS-specific range only two are left (GNU_IFUNC is 
the taken one in that range).  That's too few to waste it on this very 
specific purpose.  A second symtab-like structure might work out, but 
then, what about attribute(frobnicate)?  Or one of the other actually 
existing ones that influence codegen?  Extending debuginfo might be an 
idea, but will bloat it even more.  Tears everywhere.

Just stay with probalistic hacking?  :-)  (And see below)

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

You could add another mode of operation in objtool that merely scans all 
disassembled function bodies and emits a new list of candidate noreturn 
functions.  You run it from time to time to see if the hard-coded list is 
still sensible.

Ciao,
Michael.