I noticed that when a ThreadPlanStepOverBreakpoint is discarded (as opposed to being popped from the stack), MischiefManaged() is not called and the disabled breakpoint is not re-enabled.
Is this the intended behavior ?
-Philippe
My suspicion is that the one and only person who knows the answer to that is Jim Ingham, and he won’t be available to answer that for roughly another week.
That is intended behavior. MischiefManaged is called when an stop propagates to that plan, and it needs to decide whether it is done or not. That’s not what happens when somebody decides to discard the plan. WillPop will get called if you need to do some cleanup when the plan gets popped.
Was this causing some problem?
Jim
Sorry for the delay, I revisited the issue today.
It is causing a problem for our architecture which does not support single instruction stepping. We emulate it with breakpoints and a processor exception on branch taken.
For example:
When we step over a line with a breakpoint, our flavor of StepOverRange inserts a breakpoint at the next likely instruction and enables processor branch exception. LLDB will queue StepOverRange and StepOverBreakpoint plans.
The problem occurs when we stop on the breakpoint inserted by StepOverRange. ThreadPlanStepOverBreakpoint::DoPlanExplainsStop will see the stop reason is eStopReasonBreakpoint and ignore the breakpoint. Then StepOverRange’s DoPlanExplainsStop will claim it and ThreadPlanStepOverBreakpoint gets discarded and does not reinsert the original breakpoint.
Is there a way to make our scenario fit in the default thread plans?
Maybe check the breakpoint kind of all ‘step’ breakpoints and set the thread’s StopReason to Trace?
-Philippe
Eh, should probably actually say something, no...
Would it be sufficient to call ThreadPlanStepOverBreakpoint::ReenableBreakpointSite to reenable the breakpoint you were stepping over in ThreadPlanStepOverBreakpoint::WillPop? It won't hurt to enable it twice, once in MischiefManaged and once in WillPop. You might even get away with doing it only in WillPop and not in MischiefManaged, since no other thread plans are consulted between MischiefManaged and WillPop. The fact that you've moved the re-enabling from MM to WP should not be detectable. And it seems wrong that you should be able to get rid of a "StepOverBreakpoint" plan without re-enabling the breakpoint, so this was clearly just an oversite.
BTW, you don't want to change the stop reason to trace. Instruction single stepping onto a breakpoint, and actually hitting the breakpoint should look the same to the higher layers of the debugger.
Jim