ddb: remove some dead code from the amd64 stack unwinder

[markj]

Summary

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.

[jhb]

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.

[markj]

In D2857#55658, @jhb wrote:

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 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.

[markj]

• Restore trap frame handling: it'll be fixed properly in a new change.
• Remove more remnants of argument printing support.