https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119279
--- Comment #10 from peterz at infradead dot org --- On Fri, Mar 14, 2025 at 09:41:07AM +0000, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119279 > > --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to peterz from comment #8) > > There is the additional constraint that as long as the frame pointer > > unwinder does not have to guess, it is assumed to be 100% correct. > > > > By having calls before frame setup, we get functions missing from the > > unwind. This means that unwind can no longer be relied upon to determine > > live-ness of a function. > > > > Live Patch in particular relies on this; it needs to determine if a > > function is in-use. Notably replacing functions that are in-use is a > > very bad idea. > > So you build with -fno-optimize-sibling-calls and somehow ensure that the > kernel never uses [[gnu::musttail]], [[clang::musttail]] or > __attribute__((musttail)) (those will tail call even if > -fno-optimize-sibling-calls)? No, tail calls are not a problem. The JMP is done instead of RET, this frame is done. The new function will set up a new frame. There is absolutely no difference between doing RET or JMP from the in-use perspective. After either, the function is done and no longer used. For some purposes (call-graph reconstruction etc.) tail-calls are a pain in the arse because they make the original function go missing from unwindws, but from a live-ness pov it doesn't matter, the function is complete.
