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?
--
Alex, Kernel Hacker: http://www.bennee.com/~alex/
"Mach was the greatest intellectual fraud in the last ten years."
"What about X?"
"I said `intellectual'."
;login, 9/1990
On Wed, 2004-10-06 at 17:37, 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.
> <snip>
It would of been helpful if I'd actually attached the patch. Doh!
--
Alex, Kernel Hacker: http://www.bennee.com/~alex/
Test input for validity and plausibility.
- The Elements of Programming Style (Kernighan & Plaugher)
On Mittwoch, 6. Oktober 2004 18:39, Alex Bennee wrote:
> On Wed, 2004-10-06 at 17:37, 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.
> > <snip>
>
Note that there already is similar functionality on s390, possibly on
other architectures as well. In kernel/sysctl.c, there is code
to make the behavior run-time selectable. The sysctl is currently called
KERN_S390_USER_DEBUG_LOGGING and compiled in only for s390, but it might
be a good idea to define this in an architecture independent way, e.g.
with a config option that is always selected on s390, sh and possibly
other archs.
Arnd <><
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.
*[email protected]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
Hi All,
I'm porting linux sh onLogic PD lsh7760-10 board.
The sh4 7760 doesn't have an on chip RTC (while other sh4 processors does),
and the board I'm working on seems to have no RTC (maybe I2C bus connected).
So in such application I think there is no RTC available; what is the best way
to describe this? I think to write rtc.c rtc.h modules and write the related
funcions doing nothing.
Is it correct?
Thanks a lot
Fabio
Neil Horman wrote:
> 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.
I've some info on this here:
http://www.pixelbeat.org/libs/backtrace.c
P?draig.