The stack trace exception handler is probably the most useful tool in the firmware developer s bag of tricks. The stack trace allows the developer to view the function nesting whenever the program is stopped at a breakpoint. Because the stack trace gives an instant view of the calling history, a stack trace can save gobs of debug and analysis time.

Stack trace capability is usually considered something that is only offered by a high-level debug environment. This doesn t have to be the case. Having implemented stack trace for a few different CPUs, I can tell you that implementing stack trace is a pain in the neck; once it works, however, you just can t live without it.

The monitor-based stack trace I discuss in this chapter extracts symbol information from the symbol table file, as have other commands. The stack trace, though, requires that the symbols be sorted in ascending address order. I also limit the monitor-based stack trace to provide function nesting only.

I limit the stack trace to function nesting because deciphering variables in the stack is a bit more complicated. Think about it for a minute: return addresses must be easy to find because the hardware must use a return address every time it returns from a function call. On the other hand, finding a variable within the stack isn t a hardware function it s part of the virtual machine fabricated by the compiler. In fact, different compilers for the same CPU can use different conventions...