summaryrefslogtreecommitdiff
path: root/sys/dev
diff options
context:
space:
mode:
authorscw <scw@NetBSD.org>1999-04-04 11:33:02 +0000
committerscw <scw@NetBSD.org>1999-04-04 11:33:02 +0000
commitf7a019c61a124bb72d115bdda869c57be06a88e1 (patch)
treeb5e89204fd96ebcb25caf81077360c6e80e4bec5 /sys/dev
parenta6a272d18aa2bb87964a497cf0fe8a5452463139 (diff)
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.
Diffstat (limited to 'sys/dev')
0 files changed, 0 insertions, 0 deletions