This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: MIPS stack tracing
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Don Bowman <don at sandvine dot com>
- Cc: "'gdb at sources dot redhat dot com'" <gdb at sources dot redhat dot com>
- Date: Fri, 1 Feb 2002 14:32:59 -0500
- Subject: Re: MIPS stack tracing
- References: <FE045D4D9F7AED4CBFF1B3B813C853371BC1C2@mail.sandvine.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