Re: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in aesni-intel_asm.S

[Josh Poimboeuf <jpoimboe@redhat.com>]

On Tue, Jul 21, 2015 at 10:00:16AM +0200, Ingo Molnar wrote:
> 
> * Josh Poimboeuf <jpoimboe@redhat.com> 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@redhat.com> 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