Stack traces

[Till Straumann]

I work on a PowerPC and have my exception handler
print a stacktrace very much like the one mentioned
by the person using Coldfire.

Since I want to find the reason for the crash, I end
up using a disassembled dump of the code anyways
and hence I trace back 'manually'. This gives me
much more information (along with the register
contents that were dumped by the exception handler)
than I could get by just having the function names.

Also, I use an exception handler which doesn't kill
the system but who tries to just suspend the
offending task. Hence, in many cases I have a 'live'
system and am still able to get memory dumps etc.

-- Till

gregory.menke at gsfc.nasa.gov wrote:

> > 
> > On the Coldfire I dump a stack trace or attempt to by using Coldfire 
> > specifics for the stack (fp (a6) linking etc) to the console. This is a 
> > hex dump of the form:
> > 
> > 0x12345678 (0x12345678, 0x12345678, 0x12345678, 0x12345678)
> > 
> > This output can be feed to a small perl/awk/what-ever script and the 
> > addr2line tool turned into a source code stack trace of the functions 
> > and arguments that is close enough to help solve a specific problem. 
>
>I was thinking along these lines as well- I looked closely at the MIPS
>& mcp750 stack frames and it should be fairly easy to trace thru
>them.  I'll give it a try pretty soon.  I was thinking it would also
>be helpful to optionally print function names- though theres a bit of
>a chicken & egg problem with getting both them and their addresses
>into a .data segment somewhere.  I'll think of something...
>
>Thanks,
>
>Gregm
>