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 > On Nov 30, 2015, at 5:24 PM, Jim Ingham via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > >> On Nov 25, 2015, at 1:05 PM, Philippe Lavoie <philippe.lav...@octasic.com> >> wrote: >> >> 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 >> >> From: jing...@apple.com [jing...@apple.com] >> Sent: Monday, October 05, 2015 5:26 PM >> To: Philippe Lavoie >> Cc: lldb-dev@lists.llvm.org >> Subject: Re: [lldb-dev] ThreadPlanStepOverBreakpoint behavior >> >> 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 >> >>> On Sep 25, 2015, at 1:51 PM, Philippe Lavoie via lldb-dev >>> <lldb-dev@lists.llvm.org> wrote: >>> >>> >>> 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 >>> _______________________________________________ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
