well, ddb can normally do a backtrace past a trap frame.
I tried setting a breakpoint in uvm_fault() and I eventually
found a point where copyinstr() had taken a page fault.
the stack trace went thru the trap frame into the syscall
that triggered it.  I did notice that ddb sometimes loses
the stack trace depending on exactly which instruction it's
stopped on (I was single-stepping around some).

also note that in the trace from gdb below, 0xefbfd47c is a user address.
something is still fishy here.

-Chuck


Manuel Bouyer writes:
> On Sat, Mar 27, 1999 at 08:21:50PM -0500, Bill Sommerfeld wrote:
> > Perhaps the debugger may had difficulty tracing through the trap
> > frame...  (gdb seems to have this difficulty on i386.. tracebacks stop
> > at the trap frame.  i haven't looked into fixing this).
> 
> That may be it: looking at the kernel core dump with gdb gives:
> (gdb) where
> #0  0xf01c8450 in cpu_reboot ()
> #1  0xf01c84b3 in cpu_reboot ()
> #2  0xf010b6a5 in db_fncall ()
> #3  0xf010b310 in db_command ()
> #4  0xf010b54a in db_command_loop ()
> #5  0xf010e022 in db_trap ()
> #6  0xf01c5a30 in kdb_trap ()
> #7  0xf01ceeec in trap ()
> #8  0xf0100cf9 in calltrap ()
> #9  0xf01270f1 in panic ()
> #10 0xf01cba6e in pmap_zero_page ()
> #11 0xf01bd11e in uvm_pagezero ()
> #12 0xf01b7774 in uvm_fault ()
> #13 0xf01cf1b3 in trap ()
> #14 0xf0100cf9 in calltrap ()
> can not access 0xefbfd47c, invalid translation (invalid PDE)
> can not access 0xefbfd47c, invalid translation (invalid PDE)
> Cannot access memory at address 0xefbfd47c.
> 
> --
> Manuel Bouyer <bouyer@antioche.eu.org>
> --