public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Bob Montgomery <bob.montgomery@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [RFC] Enhanced show_stack output to add backing store regs
Date: Fri, 11 Mar 2005 21:19:49 +0000	[thread overview]
Message-ID: <1110575989.498.89.camel@localhost.localdomain> (raw)
In-Reply-To: <1110566404.498.79.camel@localhost.localdomain>

On Fri, 2005-03-11 at 12:59 -0800, David Mosberger wrote:
> >>>>> On Fri, 11 Mar 2005 20:25:26 +0000, Matthew Wilcox <matthew@wil.cx> said:
> 
>   Matthew> I know your patch leaaves this unchanged, but I don't think it's helpful
>   Matthew> to show the 'show_stack' and 'show_regs' frames.  Can we get rid of them,
>   Matthew> or is there a reason they're useful?
> 
> There were useful in the early days, when I didn't trust the unwinder... ;-)
> I agree that we should drop them.  Just unwind to the interruption-frame
> (pt_regs), then start printing the frames.
> 
> That'll also be more in line with the other arches.


You might trust the unwinder, and that *might* be a reason to lop off
the top two (show regs and show stack), but I still want to see what
kernel handler was used, and it's still reassuring to be able to check
at show_stack to verify that bsp < sp to eliminate stack overflow as
the source of either the problem, or the problem with the unwinding that
follows.


I'm assuming in my example, that not printing until the interruption
frame would eliminate what is shown below, and I would like to keep
that:

 [<a000000100036b50>] die+0x150/0x280
                                spà000001200dfb40 bspà000001200d8f20
 [<a000000100036cc0>] die_if_kernel+0x40/0x60
                                spà000001200dfb40 bspà000001200d8ef0
 [<a0000001000378d0>] ia64_fault+0x150/0xac0
                                spà000001200dfb40 bspà000001200d8ea8
 [<a00000010000ad20>] ia64_leave_kernel+0x0/0x260
                                spà000001200dfc40 bspà000001200d8ea8

and not just see the stack top out at
 
 [<a0000002000689d0>] buncho_going_to_regnat+0x50/0xa0 [buncho]
                                spà000001200dfe10 bspà000001200d8e80
...

where the error occurred.

-- 
Bob Montgomery <bob.montgomery@hp.com>


  parent reply	other threads:[~2005-03-11 21:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-11 18:40 [RFC] Enhanced show_stack output to add backing store regs Bob Montgomery
2005-03-11 19:12 ` Chen, Kenneth W
2005-03-11 20:25 ` Matthew Wilcox
2005-03-11 20:59 ` David Mosberger
2005-03-11 21:00 ` Luck, Tony
2005-03-11 21:19 ` Bob Montgomery [this message]
2005-03-11 21:23 ` David Mosberger
2005-03-14 18:51 ` Alex Tsariounov
2005-03-14 19:04 ` Luck, Tony
2005-03-14 19:19 ` Alex Tsariounov
2005-03-14 23:06 ` Keith Owens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1110575989.498.89.camel@localhost.localdomain \
    --to=bob.montgomery@hp.com \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox