Re: MIPS stack tracing

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, Jan 31, 2002 at 05:27:30PM -0500, Don Bowman wrote:
> 
> The MIPS / vxworks stack tracing has always been fairly weak
> in gdb I've found. However, now with the 3.0.3 gdb, it
> is quite broken.
> 
> The problem is that the compiler emits multiple returns
> per function. The algorithm gdb follows is that specified
> by the SYSV ABI (which the compiler is breaking). I looked
> into fixing the compiler, but gave up in the short term.
> In desperation I added a magic instruction (break 4) in the
> epilogue of each function (by modifying gcc). This allowed
> me to fix my VxWorks task trace (tt).
> 
> Now, before I launch into fixing the gdb MIPS stack tracing
> code up, I thought I'd ask a few questions. I'd like to
> do it by using the symbols to find the start of each function,
> instead of by the heuristic of walking in the code. That
> would be much faster for me (I'm on an embedded platform,
> and its slow to walk the memory over the link). It would also
> be deterministic. The downside is that the stack trace won't
> work without a symbol file. Is that OK?
> The alternative is I can add support for walking to find
> my magic instruction. This isn't standard.
> The only other alternative I can see is to fix gcc up
> to not emit multiple returns. This seems to be difficult to
> add as a constraint.
> 
> Does anyone have any suggestions on a course of action
> for me to take?

I'd like to understand - and have documented somewhere - what it is
about MIPS besides the somewhat-variable frame register that makes
backtracing so much more complex.  Also, IMHO, if we have symbol
information to find the start of the function we should certainly use
it.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer