I just went and read the cvs log for this pullup. (included
below)  I suspect this pullup fixes PR port-next68k/6688
"ddb backtrace after address trap skips faulting address"
I'll test and close the pr if that's the case.

Thanks.

Darrin

"Gordon W. Ross" <gwr@netbsd.org> writes:

> I've found this change to be quite useful.  It fixes a bug in the
> DDB trace command that prevented backtrace through trap faults.
> Please pull up this file:
> 
> /src/sys/arch/m68k/m68k/db_trace.c  1.24
> 
> Thanks,
> Gordon

----------------------------
revision 1.24
date: 1999/04/04 11:33:02;  author: scw;  state: Exp;  lines: +35 -1
Fix a problem I noticed a while back but had too many other things
in the air to deal with it.
Basically, following a kernel fault (eg. dereferencing a NULL pointer
in kernel mode) a DDB 'trace' did not show the function where the
fault occurred. For example:

        db> trace
        _Debugger()
        _panic()
        _trap()
        faultstkadj()
        _pool_drain()
        _uvm_pageout()
        _start_pagedaemon()
        _proc_trampoline()
        db>

The 'faultstkadj()' line here is bogus. It is shown because the return
address to 'trap()' happens to point there, and since faultstkadj() has
no stack frame, DDB assumes it was the faulting function. In this example,
the _real_ function was pool_reclaim(), but you would have to look at
the program counter at the time of the fault to figure that one out.

This fix makes the trace command do the dirty work for you by grubbing
around in 'trap()'s argument list to find the *real* PC value at the
time of the fault, replacing the 'faultstkadj()' line with the real
function's name.
----------------------------