Avoid querying thread stop info if the thread hasn't been running

[labath]

Summary

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.

[jingham]

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.

That seems to me a safer way of getting pretty much the same acceleration.

Jim

[labath]

In D10550#190560, @jingham 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.

That is interesting. As far as I know such a thing cannot happen on linux, but I was wondering if the same is true for other platforms. I will abandon this change then.

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.

That was our line of reasoning as well. Thanks for the heads up. I will wait for the change to land.

cheers,
pl

[clayborg]

Feel free to use this but enable it only for specific triples where you know this is a valid approach. Try using the target's architecture and if it is android or linux OS, then enable this feature.

source/Target/Thread.cpp

Thread::GetStopInfo ()
     ProcessSP process_sp (GetProcess());
     const uint32_t stop_id = process_sp ? process_sp->GetStopID() : UINT32_MAX;
     if (plan_sp && plan_sp->PlanSucceeded())
     {
         return StopInfo::CreateStopReasonWithPlan (plan_sp, GetReturnValueObject(), GetExpressionVariable());
     }
     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
         {
             return m_stop_info_sp;
         }
         else
         {
             GetPrivateStopInfo ();
if (plan_ptr)
 
         while ((plan_ptr = GetPreviousPlan(plan_ptr)) != NULL)
         {
             plan_ptr->WillResume (resume_state, false);
         }
         
         // 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();
         }
     }
 
     if (need_to_resume)
     {
         ClearStackFrames();