On Tue, Jul 21, 2015 at 10:00:16AM +0200, Ingo Molnar wrote: > > * Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > > On Mon, Jul 20, 2015 at 08:30:52AM -0700, Andy Lutomirski wrote: > > > On Fri, Jul 17, 2015 at 8:56 PM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > > > The reason I suggested to put FRAME in the macro name is to try to > > > > prevent it from being accidentally used for leaf functions, where it > > > > isn't needed. > > > > > > > > > > Could someone remind me why it isn't needed for leaf functions? > > > > If a function doesn't call any other functions, then it won't ever show > > up in a stack trace unless: > > > > a) the function itself walks the stack, in which case the frame pointer > > isn't necessary; or > > > > b) The function gets hit by an interrupt/exception, in which case frame > > pointers can't be 100% relied upon anyway. > > > > I've noticed that gcc *does* seem to create stack frames for leaf functions. > > But it's inconsistent, because the early exit path of some functions will skip > > the stack frame creation and go straight to the return. > > > > We could probably get a good performance boost with the > > -momit-leaf-frame-pointer flag. Though it would make stack traces less reliable > > when a leaf function gets interrupted. > > So in theory we could resolve this during the stack walk: when we pass from the > IRQ stack to the process stack we actually know the RIP of the interrupted > context, and could include that. The problem is with the *caller* of the leaf function. Without the leaf's frame pointer there's no way to find the call site pointer on the stack, so the leaf's caller gets skipped. -- Josh -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
