Stack traces

[Chris Johns]

gregory.menke at gsfc.nasa.gov wrote:

> 
> A number of times I've gotten exceptions I'd like to trace back the
> call tree in which they occured.  We use the MSP750 bsp and a R3000
> bsp and this would be useful for both.  I'm thinking of something that
> will trace back through stack frames once an unhandled exception
> occurs (or maybe when a function that does it is invoked).  It goes a
> ways beyond what the gdb stub implements- basically it would have to
> replicate some of gdb's functionality to do it.  Does anyone know if
> something along these lines exists- or will it involve the fairly
> gruesome sounding job of extracting code from gdb?
> 


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. 
This removes the need to have GDB or any other GPL code enter the RTEMS 
source tree. The effort required is also small as addr2line does all the 
hard work.

As far as RTEMS's future is concerned I like to see all cpu's support a 
means to suspend a task that causes an unhandled exception. That is 
RTEMS does not stop only the task executing when the exception occured. 
If the target supports a network debugger that is thread aware you could 
get it to have a look and do a backtrace.

-- 
  Chris Johns, cjohns at cybertec.com.au