Page MenuHomePhabricator

[Windows] Set correct thread stop info when single-step lands on a breakpoint
ClosedPublic

Authored by amccarth on Feb 2 2016, 2:21 PM.

Details

Summary

I don't understand how this works before, but this fixes the recent test regressions on Windows in TestConsecutiveBreakpoints.py.

LLDB wasn't stopping when single-stepping onto a breakpoint. (Note that process continue from one breakpoint starts with a single-step, so you don't have to be explicitly single-stepping to run into this problem.)

The solution is to check if the single step lands on a breakpoint, and, if it does, to treat that like a breakpoint hint. Note there's a subtle difference in the PC (program counter) compared to actually hitting a breakpoint.

This fixes TestConsecutiveBreakpoints.py on Windows, and no other tests regress. Ran clang-format.

Diff Detail

Repository
rL LLVM

Event Timeline

amccarth updated this revision to Diff 46702.Feb 2 2016, 2:21 PM
amccarth retitled this revision from to [Windows] Set correct thread stop info when single-step lands on a breakpoint.
amccarth updated this object.
amccarth added a reviewer: zturner.
amccarth added a subscriber: lldb-commits.

Looks fine, but +jim just because i want' to ask about the single step when continuing from a breakpoint. Have things always been this way? I don't recall that process continue would trigger a single step but maybe I just never noticed.

jingham edited edge metadata.Feb 2 2016, 2:44 PM

Yes, it has always been this way. Whenever we are about to start up the target - for whatever reason, we check to see if there is a breakpoint at the instruction where we are starting and if so we push a "ThreadPlanStepOverBreakpoint" which removes the breakpoint, puts in the correct instruction, single steps that thread and then replaces the breakpoint and continues.

Yes, it has always been this way. Whenever we are about to start up the target - for whatever reason, we check to see if there is a breakpoint at the instruction where we are starting and if so we push a "ThreadPlanStepOverBreakpoint" which removes the breakpoint, puts in the correct instruction, single steps that thread and then replaces the breakpoint and continues.

Thanks for the confirmation. I'm still not sure how TestConsecutiveBreakpoints.py used to work on Windows, but I believe this is the right fix.

This revision was automatically updated to reflect the committed changes.