> On Jun 18, 2015, at 3:11 PM, Jim Ingham <jing...@apple.com> wrote: > > I thought about this for much the same reason just a little while ago. Turns > out OS X, it is possible for us to stop a process, and fetch all the > exceptions, but have some thread exception that wasn't quite ready to be > delivered to that thread. The next time you let the task run, that exception > will get delivered to the thread even though it is suspended. So it isn't > safe to assume that just because WE suspended a thread, it won't have an > interesting stop reason, and we had to think of another way to get around > this. > > Our alternate was to add a "get all thread stop reasons" packet to our > extended remote protocol so once you get the stop reply packet you can turn > around and get all the remaining stop reasons in one blow.
Oh, yes, and Greg is currently implementing this. Jim > > > That seems to me a safer way of getting pretty much the same acceleration. > > Jim > >> On Jun 18, 2015, at 2:42 PM, Pavel Labath <lab...@google.com> wrote: >> >> Hi jingham, clayborg, >> >> A step over operation on a single thread typically consists of several >> start-stop cycles (stepping over breakpoints, etc.). Currently, LLDB queries >> the debug server for thread stop info of all threads after each stop, even >> though the the other threads have not been running (and hence, their stop >> info >> should remain the same). This introduces significant delay if the application >> has many threads (e.g. a typical android application has about 20 threads, >> which results in about 80 redundant packets for each step operation). This >> commit makes LLDB reuse the stop reason from the previous stop if the thread >> hasn't been running, thereby reducing the stepping latency. >> >> http://reviews.llvm.org/D10550 >> >> Files: >> source/Target/Thread.cpp >> >> Index: source/Target/Thread.cpp >> =================================================================== >> --- source/Target/Thread.cpp >> +++ source/Target/Thread.cpp >> @@ -427,6 +427,12 @@ >> } >> else >> { >> + if (m_temporary_resume_state == eStateStopped || >> m_temporary_resume_state == eStateSuspended) >> + { >> + SetStopInfo(m_stop_info_sp); // This thread hasn't been >> running, so the stop info is still valid. >> + return m_stop_info_sp; >> + } >> + >> if ((m_stop_info_stop_id == stop_id) || // Stop info is valid, just >> return what we have (even if empty) >> (m_stop_info_sp && m_stop_info_sp->IsValid())) // Stop info is >> valid, just return what we have >> { >> @@ -746,8 +752,9 @@ >> >> // If the WillResume for the plan says we are faking a resume, then >> it will have set an appropriate stop info. >> // In that case, don't reset it here. >> + // Also, don't reset in case we're stopped or suspended, as the >> stop info will remain unchanged. >> >> - if (need_to_resume && resume_state != eStateSuspended) >> + if (need_to_resume && resume_state != eStateSuspended && >> resume_state != eStateStopped) >> { >> m_stop_info_sp.reset(); >> } >> >> EMAIL PREFERENCES >> http://reviews.llvm.org/settings/panel/emailpreferences/ >> <D10550.27963.patch> > _______________________________________________ lldb-commits mailing list lldb-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
