We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to

spin up a temporary "private state thread" that will respond to events from the lower level process plugins.  This check-in should work to do
that, but it is still buggy.  However, if you don't call functions on the private state thread, these changes make no difference.

This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug
server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call.

llvm-svn: 154230

1 files changed, 3 insertions, 1 deletions

diff --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
index dd0eea9f4a1..92f90c63702 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
@@ -312,8 +312,10 @@ public:
     SetCurrentThreadForRun (int tid);
 
     lldb_private::LazyBool
-    SupportsAllocDeallocMemory () const
+    SupportsAllocDeallocMemory () // const
     {
+        // Uncomment this to have lldb pretend the debug server doesn't respond to alloc/dealloc memory packets.
+        // m_supports_alloc_dealloc_memory = lldb_private::eLazyBoolNo;
         return m_supports_alloc_dealloc_memory;
     }