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

[amccarth]

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.

[zturner]

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]

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.

[amccarth]

In D16825#342279, @jingham wrote:

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.

lldb/trunk/source/Plugins/Process/Windows/Live/ProcessWindowsLive.cpp

ProcessWindowsLive::RefreshStateAfterStop()
     ThreadSP stop_thread = m_thread_list.GetSelectedThread();
     if (!stop_thread)
         return;
 
     switch (active_exception->GetExceptionCode())
     {
         case EXCEPTION_SINGLE_STEP:
         {
-            stop_info = StopInfo::CreateStopReasonToTrace(*stop_thread);
+            RegisterContextSP register_context = stop_thread->GetRegisterContext();
+            const uint64_t pc = register_context->GetPC();
+            BreakpointSiteSP site(GetBreakpointSiteList().FindByAddress(pc));
+            if (site && site->ValidForThisThread(stop_thread.get()))
+            {
+                WINLOG_IFANY(WINDOWS_LOG_BREAKPOINTS | WINDOWS_LOG_EXCEPTION | WINDOWS_LOG_STEP,
+                             "Single-stepped onto a breakpoint in process %I64u at "
+                             "address 0x%I64x with breakpoint site %d",
+                             m_session_data->m_debugger->GetProcess().GetProcessId(), pc, site->GetID());
+                stop_info = StopInfo::CreateStopReasonWithBreakpointSiteID(*stop_thread, site->GetID());
                 stop_thread->SetStopInfo(stop_info);
-            WINLOG_IFANY(WINDOWS_LOG_EXCEPTION | WINDOWS_LOG_STEP, "RefreshStateAfterStop single stepping thread %u",
-                         stop_thread->GetID());
+            }
+            else
+            {
+                WINLOG_IFANY(WINDOWS_LOG_EXCEPTION | WINDOWS_LOG_STEP,
+                             "RefreshStateAfterStop single stepping thread %u", stop_thread->GetID());
+                stop_info = StopInfo::CreateStopReasonToTrace(*stop_thread);
                 stop_thread->SetStopInfo(stop_info);
+            }
             return;
         }
 
         case EXCEPTION_BREAKPOINT:
         {
             RegisterContextSP register_context = stop_thread->GetRegisterContext();
 
             // The current EIP is AFTER the BP opcode, which is one byte.