[Lldb-commits] [PATCH] D93874: [process] fix exec support on Linux

[Jim Ingham via Phabricator via lldb-commits]

jingham added inline comments.


================
Comment at: lldb/test/API/functionalities/exec/TestExec.py:93
+        # we clear all existing thread plans.
+        thread.StepInstruction(False)
+
----------------
clayborg wrote:
> On Darwin threads have unique identifiers and the thread ID before exec != thread ID after exec. On linux, we get the same thread ID for the thread that does exec: thread ID before exec == thread ID after exec. 
> 
> So on Darwin when we stop, we will remove all thread plans that are not part of the current thread list and since the globally unique thread ID has changed, it will toss out any thread plans for the old thread. On linux this stays around and since the ID is the same, and since the thread lists gets cleared on exec, we then have a case where the thread plan outlives the thread shared pointers. The thread lists (real and user visible) are cleared in ProcessGDBRemote::SetLastStopPacket() when did_exec == true.
> On Darwin threads have unique identifiers and the thread ID before exec != thread ID after exec. On linux, we get the same thread ID for the thread that does exec: thread ID before exec == thread ID after exec. 
> 
> So on Darwin when we stop, we will remove all thread plans that are not part of the current thread list and since the globally unique thread ID has changed, it will toss out any thread plans for the old thread. On linux this stays around and since the ID is the same, and since the thread lists gets cleared on exec, we then have a case where the thread plan outlives the thread shared pointers. The thread lists (real and user visible) are cleared in ProcessGDBRemote::SetLastStopPacket() when did_exec == true.

The ThreadPlans don't rely on thread shared pointers except as a cache.  They work off the ThreadID as the primary bit of data.  They have to do this to handle the case where a thread might not be reported on one stop, and then will be reported later on, as happens with OS Plugin threads in the xnu kernel.

The thread shared pointer cache variable gets cleared on "WillResume" and then when you stop, the first time it needs to get its Thread, it looks up its owner thread by ID from the Process ThreadList.  So provided there's SOME thread with that ID after the stop, the thread plan really won't know any difference.

But more importantly, there should be no way to ask a ThreadPlan questions directly.  You are always asking the Thread something (stop reason or ShouldStop or whatever), which then forwards the request to that Thread's ThreadPlan stack.  So it shouldn't be possible to get to a ThreadPlan whose thread no longer exists.  I'd like to know how that's happening, because that's going to be a wrong thing to do in any circumstances...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93874/new/

https://reviews.llvm.org/D93874