RE: MIPS stack tracing

[Don Bowman <don at sandvine dot com>]

> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> 
> 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.

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.

For embedded platforms this is a disaster: you don't have
the full symbols (or sometimes any symbols). In desperation
I added a function end marker of 'break 4', and search 
for that instead of 'jr ra'. This is obviously a hack, but
I was stuck on our embedded system.

Now I've got the same issue with gdb. I don't want to add
the 'hack'. The algorithm its using just doesn't work. gdb
in general has access to the symbols, so I can search for
a .ent by symbol instead of by algorithm. However, this
means gdb won't be able to work without symbols if I make
the change. But it would appear that it doesn't right now
anyway.

--don