Messages in this thread | | | Date | Thu, 25 Aug 2022 08:41:19 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH] x86/sev: Mark snp_abort() noreturn |
| |
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 stops.
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.
| |