From 205afe679855a4ce8149cdaa94d3f0868ce796dc Mon Sep 17 00:00:00 2001 From: Ed Maste Date: Fri, 6 Feb 2015 21:38:51 +0000 Subject: Import LLDB as of upstream SVN r225923 (git 2b588ecd) This corresponds with the branchpoint for the 3.6 release. A number of files not required for the FreeBSD build have been removed. Sponsored by: DARPA, AFRL --- source/Target/ThreadPlanStepOverBreakpoint.cpp | 35 +++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-) (limited to 'source/Target/ThreadPlanStepOverBreakpoint.cpp') diff --git a/source/Target/ThreadPlanStepOverBreakpoint.cpp b/source/Target/ThreadPlanStepOverBreakpoint.cpp index dc011e545402..6f285e25fd0b 100644 --- a/source/Target/ThreadPlanStepOverBreakpoint.cpp +++ b/source/Target/ThreadPlanStepOverBreakpoint.cpp @@ -64,11 +64,33 @@ ThreadPlanStepOverBreakpoint::DoPlanExplainsStop (Event *event_ptr) StopInfoSP stop_info_sp = GetPrivateStopInfo (); if (stop_info_sp) { + // It's a little surprising that we stop here for a breakpoint hit. However, when you single step ONTO a breakpoint + // we still want to call that a breakpoint hit, and trigger the actions, etc. Otherwise you would see the + // PC at the breakpoint without having triggered the actions, then you'd continue, the PC wouldn't change, + // and you'd see the breakpoint hit, which would be odd. + // So the lower levels fake "step onto breakpoint address" and return that as a breakpoint. So our trace + // step COULD appear as a breakpoint hit if the next instruction also contained a breakpoint. StopReason reason = stop_info_sp->GetStopReason(); - if (reason == eStopReasonTrace || reason == eStopReasonNone) + + switch (reason) + { + case eStopReasonTrace: + case eStopReasonNone: return true; - else + case eStopReasonBreakpoint: + // It's a little surprising that we stop here for a breakpoint hit. However, when you single step ONTO a + // breakpoint we still want to call that a breakpoint hit, and trigger the actions, etc. Otherwise you + // would see the PC at the breakpoint without having triggered the actions, then you'd continue, the PC + // wouldn't change, and you'd see the breakpoint hit, which would be odd. + // So the lower levels fake "step onto breakpoint address" and return that as a breakpoint hit. So our trace + // step COULD appear as a breakpoint hit if the next instruction also contained a breakpoint. We don't want + // to handle that, since we really don't know what to do with breakpoint hits. But make sure we don't set + // ourselves to auto-continue or we'll wrench control away from the plans that can deal with this. + SetAutoContinue(false); + return false; + default: return false; + } } return false; } @@ -76,7 +98,7 @@ ThreadPlanStepOverBreakpoint::DoPlanExplainsStop (Event *event_ptr) bool ThreadPlanStepOverBreakpoint::ShouldStop (Event *event_ptr) { - return false; + return !ShouldAutoContinue(event_ptr); } bool @@ -163,3 +185,10 @@ ThreadPlanStepOverBreakpoint::ShouldAutoContinue (Event *event_ptr) { return m_auto_continue; } + +bool +ThreadPlanStepOverBreakpoint::IsPlanStale() +{ + return m_thread.GetRegisterContext()->GetPC() != m_breakpoint_addr; +} + -- cgit v1.3