Re: MIPS stack tracing

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Feb 01, 2002 at 01:14:44PM -0500, Don Bowman wrote:
> > 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.

For embedded systems, you'd have to disable the multiple-return
optimizations.  This is actually very simple to do, though I don't
remember off-hand.  If you ask on gcc@gcc.gnu.org what change it is you
would need to make to the MD file to get a compiler that didn't do
this, I'm sure they can tell you.  If you argue convincingly enough
they might even revert (or at least add a flag).

This is not the right way for GDB to backtrace, however.  On most
architectures GDB gets a very minimal backrace with no symbols; I
personally am fine with giving none at all.  Does anyone out there
really object?


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