[PATCH 7/7] powerpc/64/kdump: Use ppc_save_regs() in crash_setup_regs()
Anton Vorontsov
avorontsov at ru.mvista.com
Wed Jan 7 15:04:20 EST 2009
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 <avorontsov at ru.mvista.com>
> > ---
>
> 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: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2
More information about the Linuxppc-dev
mailing list