MIPS stack tracing

[David Anderson <davea@quasar.engr.sgi.com>]

Don Bowman <don@sandvine.com> writes:
> 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?

Whether it's ok for gdb is for others  to say.
SGI debuggers long ago went this route.

Daniel Jacobowitz <drow@mvista.com> writes:
|The stack tracing algorithm for MIPS is defined in
|the SYSV ABI, @ http://www.caldera.com/developers/devspecs/
|Its fairly straightforward and works reliably.
|
|The gist of it is, walk backwards until you find 'jr ra',
|then walk forwards to the first non-null instruction. That's
|the start of a function. Look for a [d]addiu to the sp, that's
|the stack adjustment, look for a [d]addiu to the fp, that's
|the frame. Look for a s[w|d] of ra to the stack.
|Continue on up the stack.
|
|However, gcc 3.0 is breaking the rules. It emits multiple
|'jr ra' per function. Unfortunately, this appears to be
|rather tough to fix. The upshot is that the beginning of
|a function can't be reliably found, and it all falls apart
|from there. Prior to gcc 3.0 it was fine.

That ABI document was written for and applies to the MIPS-I
processors available at the time.
AFAIK, the organization that maintained that document disbanded
a few years ago.

As I said in an earlier note, the ABI document was not always honored
(though it should have been) even back in the early 1990's
but today that Mips Processor Supplement is simply
not applicable.  Much has not changed, but key things
have changed (new registers and
new instructions).  I don't know of a replacement document
(other than SGI documents).

http://www.mips.com has the
MIPSpro assembly language document (vol 1 and 2)
which is (or was) an SGI document describing the n32 
calling conventions.   
(you have to register to see the document, but there is no charge).
Also available from http://techpubs.sgi.com

Corrections welcome.
David Anderson davea@sgi.com