[lldb-dev] "step" threading issues
gclayton at apple.com
Mon Apr 29 09:23:38 PDT 2013
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:
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 <ck at remobjects.com> 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();
>>> 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
> lldb-dev at cs.uiuc.edu
More information about the lldb-dev