A general stability fix where we _always_ get the thread list immediately after we get the stop packets. We had some racy conditions where thread 1 might be sending a packet and thread 2 tries to send a packet to get the thread list and it fails and ends up with an empty list. Packets use a sequence mutex to be able to ensure when you send a packet, you get the resonse. This sequence mutex is take when the process is running, and as we exit the running state and notify our process with the stop packet, we now always get the thread ID list before we do anything and before we can run into race conditions.
The next step is to have our stop reply packets send the thread list in the actual stop reply packet to avoid a 2 packet overhead of sending the qfThreadInfo + response and qfThreadInfo + response.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154376 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h b/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
index a41957f..6a0758b 100644
--- a/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ b/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -307,6 +307,8 @@
typedef std::vector<lldb::tid_t> tid_collection;
typedef std::vector< std::pair<lldb::tid_t,int> > tid_sig_collection;
typedef std::map<lldb::addr_t, lldb::addr_t> MMapMap;
+ tid_collection m_thread_ids; // Thread IDs for all threads. This list gets updated after stopping
+ lldb_private::Mutex m_thread_ids_mutex;
tid_collection m_continue_c_tids; // 'c' for continue
tid_sig_collection m_continue_C_tids; // 'C' for continue with signal
tid_collection m_continue_s_tids; // 's' for step
@@ -336,6 +338,12 @@
SetThreadStopInfo (StringExtractor& stop_packet);
void
+ ClearThreadIDList ();
+
+ bool
+ UpdateThreadIDList ();
+
+ void
DidLaunchOrAttach ();
lldb_private::Error