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

From: Peter Zijlstra <peterz@infradead.org>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Borislav Petkov <bp@alien8.de>, X86 ML <x86@kernel.org>,
	Michael Matz <matz@suse.de>,
	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: Wed, 24 Aug 2022 22:45:12 +0200	[thread overview]
Message-ID: <YwaN2HtMyM0YEdSB@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20220824172929.GA25951@gate.crashing.org>

On Wed, Aug 24, 2022 at 12:29:29PM -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, Aug 24, 2022 at 05:24:20PM +0200, Borislav Petkov wrote:
> > Mark both the function prototype and definition as noreturn in order to
> > prevent the compiler from doing transformations which confuse objtool
> > like so:
> > 
> >   vmlinux.o: warning: objtool: sme_enable+0x71: unreachable instruction
> 
> Would -Wmissing-noreturn have caught this?  It sounds like you need this
> (and then fix all resulting warnings) to not upset objtool?
> 
> It is nice to have this anyway (if there aren't a zillion false
> positives), but it seems objtool is very fragile.

Well, just like gcc has noreturn heuristics so has objtool, it just
turns into pain when they don't agree with one another.

Ideally noreturn would be reflected in the object file so we don't have
to guess at it. 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.

Another options is something like .symtab.noreturn which is another
symbol table explicitly listing the noreturn functions. Since it's an
extra section tools that don't know about it can freely ignore it and
carry on as usual.