Subject: CVS commit: src
To: None <source-changes@netbsd.org>
From: Steve Woodford <scw@netbsd.org>
List: source-changes
Date: 04/04/1999 04:33:03
Module Name:	src
Committed By:	scw
Date:		Sun Apr  4 11:33:02 UTC 1999

Modified Files:
	src/sys/arch/m68k/m68k: db_trace.c
Log Message:
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.