MIPS stack tracing

[Don Bowman <don@sandvine.com>]

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?

--don