Subject: Re: [PATCH 7/7] powerpc/64/kdump: Use ppc_save_regs() in crash_setup_regs()

From: Anton Vorontsov <[email-masked]>
Date: Wed, 7 Jan 2009 07:04:20 +0300

On Wed, Jan 07, 2009 at 02:16:05PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2008-12-17 at 23:09 +0300, Anton Vorontsov wrote:
> > The patch replaces internal registers dump implementation with
> > ppc_save_regs(). From now on PPC64 and PPC32 are using the same
> > code for crash_setup_regs().
> > 
> > NOTE: The old regs dump implementation was capturing SP (r1) directly
> > as is, so you could see crash_kexec() function on top of the back-trace.
> > But ppc_save_regs() goes up one stack frame, so you'll not see it
> > anymore, at the top-level you'll see who actually triggered the crash
> > dump instead.
> > 
> > Signed-off-by: Anton Vorontsov <[email-masked]>
> > ---
> 
> Note that ppc_save_regs() for some obscure reason isn't saving r1...
> 
> Is that a problem for you ? I think we should fix ppc_save_regs()
> anyway, it doesn't matter for xmon to save one more register and it will
> avoid nasty surprises in the long run.

AFAICS it saves r1:

       PPC_STL r0,0*SZL(r3)
       PPC_STL r2,2*SZL(r3)
       PPC_STL r3,3*SZL(r3)
       ...
       /* go up one stack frame for SP */
       PPC_LL  r4,0(r1)
       PPC_STL r4,1*SZL(r3)

This fact is mentioned in the patch description:

 NOTE: The old regs dump implementation was capturing SP (r1) directly
 as is, so you could see crash_kexec() function on top of the back-trace.
 But ppc_save_regs() goes up one stack frame, so you'll not see it
 anymore, at the top-level you'll see who actually triggered the crash
 dump instead.

Do you see anything wrong in such behaviour?

Thanks,

-- 
Anton Vorontsov
email: [email-masked]
irc://irc.freenode.net/bd2