None of the callers of db_backtrace() pass a trap frame, so don't bother
attempting to decode the current instruction. This change is a precursor
to a couple of bug fixes for the unwinder and introduces no functional
changes.
Details
- Reviewers
peter jhb - Commits
- rS285773: Remove some dead code from DDB's amd64 stack unwinder.
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage
Event Timeline
Removing the numargs stuff is definitely fine.
I think the trapframe bit is probably a bug in db_trace_thread(). It should be passing kdb_frame when kdb_thread is used. kdb_thr_ctx() does some of this already as it creates a fake pcb that is used to pass
the PC and sp values derived from kdb_frame. I bet some of the KDB changes several years ago broke this. However, I'm not sure how you would reproduce it. Perhaps a kernel module with an int3 instruction at specific points in a function prologue would be able to test it, but that would be tedious.
I also wonder if db_nextframe() should use similar logic to construct the frame it builds "below" the trapframe. In that case it would need to be done in a shared function, and you could probably do it explicitly in db_trace_thread() for the kdb_thread case and not keep it in db_backtrace().
If you do remove the special trapframe handling, you should do so on both amd64 and i386.
I see. Looks like this was broken by r131952. It should be possible to use DDB to put a breakpoint on a function prologue, so I'll give that a try and see if I can fix this.
I also wonder if db_nextframe() should use similar logic to construct the frame it builds "below" the trapframe. In that case it would need to be done in a shared function, and you could probably do it explicitly in db_trace_thread() for the kdb_thread case and not keep it in db_backtrace().
If you do remove the special trapframe handling, you should do so on both amd64 and i386.
- Restore trap frame handling: it'll be fixed properly in a new change.
- Remove more remnants of argument printing support.