On Tue, Apr 18, 2000 at 11:12:48PM -0700, Ethan Solomita wrote:

 > > Also, isn't MIPS stack unwinding inherent unreliable?  Certainly seems
 > > so in userland (fencepost errors and such from gdb) - it the kernel a
 > > little more well behaved in this respect?
 > > 
 > 	This seems a reasonable concern. We'll be able to backtrace as well as
 > "trace" can within ddb. I think that it's pretty reliable for the trace,
 > although not the arguments to functions. It can't backtrace behind a few
 > of the trap/interrupt/etc entry functions, but I think that that should
 > be fine.

Actually... Please take a look at the Alpha db_trace.c ... Ross and I
made that one work pretty well.  The one thing it does require is for
a DDB symbol table to be loaded, but that's okay, really.  A small price
to pay.

The Alpha db_trace is able to trace back across traps, tell you what
system call the user issued, and all that nifty stuff.

Part of what makes it easy is that the Alpha port uses the same-size
exception frame for all exceptions.  The MIPS port may not do this; I
seem to remember there are a couple of places where the exception frame
sizes are different e.g. when DDB is configured into the kernel.

This part needs to be fixed if the MIPS db_trace is to be made reliable.
A standard exception frame size should be decided upon, and that frame
always allocated on the stack during an exception.  In the case where you
don't want to save all of the registers (i.e. the ! DDB example I cited
above), simple don't store the registers on the stack frame if you want
to avoid those memory accesses.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>