[Lldb-commits] [lldb] [lldb][gdb-remote] Mark thread as stopped in RefreshStateAfterStop (PR #201605)

[Charles Zablit via lldb-commits]

https://github.com/charles-zablit created https://github.com/llvm/llvm-project/pull/201605

Currently, the default state of a thread is `eStateUnloaded`. However, `ThreadList::DidStop` only converts threads that were`eStateRunning` to `eStateStopped`. Because of this, new threads stay `eStateUnloaded` forever, and `SBThread::IsStopped()` returns false.

On Windows, `TargetThreadWindows::RefreshStateAfterStop` calls `SetState(eStateStopped)`. When using `LLDB_USE_LLDB_SERVER=1`, lldb uses the gdb-remote code path, which does not have that fix, causing `TestThreadStates::test_state_after_breakpoint` and `TestBreakAfterJoin` to fail.

This patch ports the fix to `ThreadGDBRemote`. When running with `LLDB_USE_LLDB_SERVER=1`, it fixes:
- `TestThreadStates::test_state_after_breakpoint`
- `TestBreakAfterJoin`

This could help fix llvm.org/pr15824 on POSIX.

rdar://178727939

>From 0821514e7df7d045d4861c61242604c45865d077 Mon Sep 17 00:00:00 2001
From: Charles Zablit <c_zablit at apple.com>
Date: Thu, 4 Jun 2026 15:33:16 +0100
Subject: [PATCH] [lldb][gdb-remote] Mark thread as stopped in
 RefreshStateAfterStop

---
 lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp b/lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
index c0171734343a6..86c9843eeedd8 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
@@ -271,6 +271,9 @@ void ThreadGDBRemote::WillResume(StateType resume_state) {
 }
 
 void ThreadGDBRemote::RefreshStateAfterStop() {
+  // Mark this thread as stopped. ThreadList::DidStop only transitions
+  // threads from a running state to stopped.
+  SetState(eStateStopped);
   // Invalidate all registers in our register context. We don't set "force" to
   // true because the stop reply packet might have had some register values
   // that were expedited and these will already be copied into the register