You should only get one stopped event unless you are hitting a breakpoint that
continues your target. In this case the eStateStopped event would be a
"restarted" event which can be found out by:
static bool
SBProcess::GetRestartedFromEvent (const lldb::SBEvent &event);
This means the program stopped but restarted automatically. You should never
see two eStateStopped events in a row, if you are, please try and reproduce on
a Mac target and file a bug.
For step into, the stop reason should always be eStopReasonPlanComplete.
On Apr 29, 2013, at 7:33 AM, Carlo Kok <[email protected]> wrote:
> Op 29-4-2013 15:43, Carlo Kok schreef:
>> Op 29-4-2013 15:40, Carlo Kok schreef:
>>> I'm calling when my users want to "step into" a function:
>>>
>>>
>>> SBThread th= self->m_process.GetSelectedThread();
>>> th.StepInto();
>>>
>>> When it's done I get notified in the way of my process listener:
>>> case SBProcess::eBroadcastBitStateChanged:
>>> int n = self->m_process.GetStateFromEvent (data);
>>> where n is eStateStopped, however at this point when I read :
>>>
>>> m_process.GetSelectedThread().GetStopReason() it returns eStopReasonNone
>>> half the time, but never when I'm debugging. This is a simple threaded
>>> all. How should I find out if ti returned from a plan?
>>
>> I have to add to this that it ONLY happens for Step Into for some reason.
>>
>
> And an addition to that: I get several eStateStopped events in sequence when
> this happens.
>
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
