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
