Re: [PATCH v3 5/6] x86/ftrace: Use text_poke()

[Jiri Kosina]

On Tue, 28 Jan 2020, Josh Poimboeuf wrote:

> > For the cases I've seen so far, it has always been gcc deciding under 
> > certain circumstances not to propagate __attribute__((__noreturn__)) from 
> > callee to caller even in the cases when caller unconditionally called 
> > callee.
> > 
> > AFAIU, the behavior is (and always will) be dependent on the state of gcc 
> > optimizations, and therefore I don't see any other way than adding 
> > __noreturn anotation transitively everywhere in order to silence objtool.
> > 
> > So those cases have to be fixed anyway.
> > 
> > What are the other cases please? Either I have completely missed those, or 
> > they haven't been mentioned in this thread.
> 
> For example, see:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/commit/?h=objtool-fixes&id=6265238af90b395a1e5e5032a41f012a552d8a9e
> 
> Many of those callees are static noreturns, for which we've *never*
> needed annotations.  Disabling -fipa-pure-const has apparently changed
> that.

For some reason I thought you were talking about static inlines, sorry for 
the noise.

Yeah, so I agree with you -- whether we need those anotations depends on 
compiler implementation of optimizations, and most importantly on (the 
current state of) internal implementation of specific optimizations in 
gcc.

Leaving live patching completely aside for the sake of this discussion for 
now -- I believe we either fully rely on gcc to propagate the 'noreturn' 
propery throughout the callstack upward, or we don't.

If we don't, then we do need the anotations (both the global and static 
ones), and problem solved.

If we do, well, where is the 'this is *the* behavior of any current/future 
clang^Wcompiler' invariant guarantee?

Thanks,

-- 
Jiri Kosina
SUSE Labs