Page MenuHomeFreeBSD

ddb: remove some dead code from the amd64 stack unwinder
ClosedPublic

Authored by markj on Jun 18 2015, 5:21 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 28, 12:59 PM
Unknown Object (File)
Thu, Nov 28, 12:58 PM
Unknown Object (File)
Thu, Nov 28, 12:57 PM
Unknown Object (File)
Tue, Nov 19, 1:22 AM
Unknown Object (File)
Sun, Nov 17, 2:33 AM
Unknown Object (File)
Mon, Nov 11, 7:32 PM
Unknown Object (File)
Thu, Nov 7, 5:42 PM
Unknown Object (File)
Oct 2 2024, 6:39 PM
Subscribers

Details

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.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage

Event Timeline

markj retitled this revision from to ddb: remove some dead code from the amd64 stack unwinder.
markj edited the test plan for this revision. (Show Details)
markj updated this object.

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.

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 edited edge metadata.
  • Restore trap frame handling: it'll be fixed properly in a new change.
  • Remove more remnants of argument printing support.
jhb edited edge metadata.
This revision is now accepted and ready to land.Jul 21 2015, 4:53 AM
This revision was automatically updated to reflect the committed changes.