All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@redhat.com>
To: Alex Bennee <kernel-hacker@bennee.com>
Cc: "LinuxSH (sf)" <linuxsh-dev@lists.sourceforge.net>,
	"Linux-SH (m17n)" <linux-sh@m17n.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] RFC. User space backtrace on segv
Date: Wed, 06 Oct 2004 13:34:50 -0400	[thread overview]
Message-ID: <41642CBA.7030709@redhat.com> (raw)
In-Reply-To: <1097080652.5420.34.camel@cambridge>

Alex Bennee wrote:
> Hi,
> 
> I hacked up this little patch to dump the stack and attempt to generate
> a back-trace for errant user-space tasks.
> 
> What:
> 
> Generates a back-trace of the user application on (in this case) a segv
> caused by an unaligned access. This particular patch is against 2.4.22
> on the SH which is what I'm working with but there no reason it couldn't
> be more generalised.
> 
> How:
> 
> Its not the most intelligent approach as it basically walks up the stack
> reading values and seeing if the address corresponds to one of the
> processes executable VMA's. If it matches it assumes its the return
> address treats that section as a "frame"
> 
> Why:
> 
> I work with embedded systems and for a myriad of reasons doing a full
> core dump of the crashing task is a pain. Often just knowing the
> immediate call stack and local variables is enough to look at what went
> wrong with objdump -S.
> 
> Questions:
> 
> Have I replicated anything that is already hidden in the code base?
> Would this be useful (as a CONFIG_ option) for embedded systems?
> 


IIRC, there is already a backtrace function defined for most arches in 
the c library.  in execinfo.h there is a family of backtrace functions 
that can unwind the stack fairly well for most arches, and store the 
trace in a post SIGSEGV-safe fashion.

Neil

-- 
/***************************************************
  *Neil Horman
  *Software Engineer
  *Red Hat, Inc.
  *nhorman@redhat.com
  *gpg keyid: 1024D / 0x92A74FA1
  *http://pgp.mit.edu
  ***************************************************/

  parent reply	other threads:[~2004-10-06 17:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-06 16:37 [PATCH] RFC. User space backtrace on segv Alex Bennee
2004-10-06 16:39 ` Alex Bennee
2004-10-06 17:17   ` Arnd Bergmann
2004-10-06 17:34 ` Neil Horman [this message]
2004-10-07  9:48   ` P
2004-10-07 10:29   ` RTC (real time clock) question about sh4 7760 Fabio Giovagnini

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=41642CBA.7030709@redhat.com \
    --to=nhorman@redhat.com \
    --cc=kernel-hacker@bennee.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@m17n.org \
    --cc=linuxsh-dev@lists.sourceforge.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.