Stack traces

[gregory.menke at gsfc.nasa.gov]

 > 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.
 > 

We regularly use objdumps to trace things.  But, i've found a couple
times that I really could use the actual call tree, as sometimes its
helpful to know where a call tree started from.  Particularly so when
you end up in a generic fatal error and have no idea where things were
when the error happened.  This would be particularly useful for
diagnosing problems during rtems initialization- before the app even
starts up.

I was thinking of function names only as a convienence for the
operator- probably I'll print the various addresses, a few argument
registers and maybe relevant stack frame things.

Our exception handler also has the option of resuming- its mostly up
to the user to either set the vector to a no-op routine or do
something useful rather than a panic.

Gregm