l 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..
; -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 cal
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
Su
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.
Wa
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.
On Fri, Sep 25, 2015 at 1:51 PM, Philippe Lavoie via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
> I noticed that when a ThreadPlanStepOverB
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
