[Lldb-commits] [PATCH] D128152: [lldb] [llgs] Support multiprocess in qfThreadInfo
mgorny added a comment. Ok, apparently the changes that's breaking this is replacing the `OK` response with `l` when there's no debugged process. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D128152/new/ https://reviews.llvm.org/D128152 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D128152: [lldb] [llgs] Support multiprocess in qfThreadInfo
mgorny added a comment. I've reverted the code changes and marked my new tests xfail. I will attempt to find the problem in the new code later. Once again, I'm sorry for missing this. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D128152/new/ https://reviews.llvm.org/D128152 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D128152: [lldb] [llgs] Support multiprocess in qfThreadInfo
mgorny added a comment. I'm sorry, it is indeed my fault. I'm going to try to fix it shortly, and if I don't manage to figure it out, I'm going to revert this and the commits depending on it. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D128152/new/ https://reviews.llvm.org/D128152 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D128152: [lldb] [llgs] Support multiprocess in qfThreadInfo
mgorny added a comment. Thanks for the notice. I was pretty sure it failed to me prior to my changes but it is possible that I read the output wrong, so I'm going to check it now. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D128152/new/ https://reviews.llvm.org/D128152 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D128152: [lldb] [llgs] Support multiprocess in qfThreadInfo
cmtice added a comment.
Herald added a subscriber: JDevlieghere.
Just FYI, this commit appears to cause
lldb//test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py
to fail. The error I'm seeing is:
Traceback (most recent call last):
File
"../lldb/test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py",
line 72, in test_target_auto_install_main_executable
self.expect("process launch", substrs=["exited with status = 74"])
File ".../lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2295, in expect
self.runCmd(
File ".../lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1998, in runCmd
self.assertTrue(self.res.Succeeded(),
AssertionError: False is not True : Command 'process launch
Error output:
error: failed to get reply to handshake packet within timeout of 0.0 seconds
' did not return successfully
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D128152/new/
https://reviews.llvm.org/D128152
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D128152: [lldb] [llgs] Support multiprocess in qfThreadInfo
This revision was automatically updated to reflect the committed changes.
Closed by commit rG75757c86c695: [lldb] [llgs] Support multiprocess in
qfThreadInfo (authored by mgorny).
Herald added a project: LLDB.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D128152/new/
https://reviews.llvm.org/D128152
Files:
lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
Index: lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
===
--- lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
+++ lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
@@ -554,6 +554,66 @@
], True)
self.expect_gdbremote_sequence()
+@add_test_categories(["fork"])
+def test_threadinfo(self):
+self.build()
+self.prep_debug_monitor_and_inferior(
+inferior_args=["fork",
+ "thread:new",
+ "trap",
+ ])
+self.add_qSupported_packets(["multiprocess+",
+ "fork-events+"])
+ret = self.expect_gdbremote_sequence()
+self.assertIn("fork-events+", ret["qSupported_response"])
+self.reset_test_sequence()
+
+# continue and expect fork
+self.test_sequence.add_log_lines([
+"read packet: $c#00",
+{"direction": "send", "regex": self.fork_regex.format("fork"),
+ "capture": self.fork_capture},
+], True)
+self.add_threadinfo_collection_packets()
+ret = self.expect_gdbremote_sequence()
+pidtids = [
+(ret["parent_pid"], ret["parent_tid"]),
+(ret["child_pid"], ret["child_tid"]),
+]
+prev_pidtids = set(self.parse_threadinfo_packets(ret))
+self.assertEqual(prev_pidtids,
+ frozenset((int(pid, 16), int(tid, 16))
+ for pid, tid in pidtids))
+self.reset_test_sequence()
+
+for pidtid in pidtids:
+self.test_sequence.add_log_lines(
+["read packet: $Hcp{}.{}#00".format(*pidtid),
+ "send packet: $OK#00",
+ "read packet: $c#00",
+ {"direction": "send",
+ "regex": "^[$]T05thread:p{}.{}.*".format(*pidtid),
+ },
+ ], True)
+self.add_threadinfo_collection_packets()
+ret = self.expect_gdbremote_sequence()
+self.reset_test_sequence()
+new_pidtids = set(self.parse_threadinfo_packets(ret))
+added_pidtid = new_pidtids - prev_pidtids
+prev_pidtids = new_pidtids
+
+# verify that we've got exactly one new thread, and that
+# the PID matches
+self.assertEqual(len(added_pidtid), 1)
+self.assertEqual(added_pidtid.pop()[0], int(pidtid[0], 16))
+
+for pidtid in new_pidtids:
+self.test_sequence.add_log_lines(
+["read packet: $Hgp{:x}.{:x}#00".format(*pidtid),
+ "send packet: $OK#00",
+ ], True)
+self.expect_gdbremote_sequence()
+
@add_test_categories(["fork"])
def test_memory_read_write(self):
self.build()
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
@@ -159,6 +159,9 @@
PacketResult Handle_qRegisterInfo(StringExtractorGDBRemote &packet);
+ void AddProcessThreads(StreamGDBRemote &response,
+ NativeProcessProtocol &process, bool &had_any);
+
PacketResult Handle_qfThreadInfo(StringExtractorGDBRemote &packet);
PacketResult Handle_qsThreadInfo(StringExtractorGDBRemote &packet);
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1974,38 +1974,46 @@
return SendPacketNoLock(response.GetString());
}
-GDBRemoteCommunication::PacketResult
-GDBRemoteCommunicationServerLLGS::Handle_qfThreadInfo(
-StringExtractorGDBRemote &packet) {
+void GDBRemoteCommunicationServerLLGS::AddProcessThreads(
+StreamGDBRemote &response, NativeProcessProtocol &process, bool &had_any) {
Log *log = GetLog(LLDBLog::Thread);
- // Fail if we don't have a current process.
- if (!m_current_p
[Lldb-commits] [PATCH] D128152: [lldb] [llgs] Support multiprocess in qfThreadInfo
mgorny updated this revision to Diff 438914.
mgorny marked an inline comment as done.
mgorny added a comment.
Simplify to use a single loop for both multiprocess and non-multiprocess modes.
Replace the static function with `include_pid` with a class method, to prepare
for adding a new helper to print PID+TID.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D128152/new/
https://reviews.llvm.org/D128152
Files:
lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
Index: lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
===
--- lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
+++ lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
@@ -554,6 +554,66 @@
], True)
self.expect_gdbremote_sequence()
+@add_test_categories(["fork"])
+def test_threadinfo(self):
+self.build()
+self.prep_debug_monitor_and_inferior(
+inferior_args=["fork",
+ "thread:new",
+ "trap",
+ ])
+self.add_qSupported_packets(["multiprocess+",
+ "fork-events+"])
+ret = self.expect_gdbremote_sequence()
+self.assertIn("fork-events+", ret["qSupported_response"])
+self.reset_test_sequence()
+
+# continue and expect fork
+self.test_sequence.add_log_lines([
+"read packet: $c#00",
+{"direction": "send", "regex": self.fork_regex.format("fork"),
+ "capture": self.fork_capture},
+], True)
+self.add_threadinfo_collection_packets()
+ret = self.expect_gdbremote_sequence()
+pidtids = [
+(ret["parent_pid"], ret["parent_tid"]),
+(ret["child_pid"], ret["child_tid"]),
+]
+prev_pidtids = set(self.parse_threadinfo_packets(ret))
+self.assertEqual(prev_pidtids,
+ frozenset((int(pid, 16), int(tid, 16))
+ for pid, tid in pidtids))
+self.reset_test_sequence()
+
+for pidtid in pidtids:
+self.test_sequence.add_log_lines(
+["read packet: $Hcp{}.{}#00".format(*pidtid),
+ "send packet: $OK#00",
+ "read packet: $c#00",
+ {"direction": "send",
+ "regex": "^[$]T05thread:p{}.{}.*".format(*pidtid),
+ },
+ ], True)
+self.add_threadinfo_collection_packets()
+ret = self.expect_gdbremote_sequence()
+self.reset_test_sequence()
+new_pidtids = set(self.parse_threadinfo_packets(ret))
+added_pidtid = new_pidtids - prev_pidtids
+prev_pidtids = new_pidtids
+
+# verify that we've got exactly one new thread, and that
+# the PID matches
+self.assertEqual(len(added_pidtid), 1)
+self.assertEqual(added_pidtid.pop()[0], int(pidtid[0], 16))
+
+for pidtid in new_pidtids:
+self.test_sequence.add_log_lines(
+["read packet: $Hgp{:x}.{:x}#00".format(*pidtid),
+ "send packet: $OK#00",
+ ], True)
+self.expect_gdbremote_sequence()
+
@add_test_categories(["fork"])
def test_memory_read_write(self):
self.build()
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
@@ -159,6 +159,9 @@
PacketResult Handle_qRegisterInfo(StringExtractorGDBRemote &packet);
+ void AddProcessThreads(StreamGDBRemote &response,
+ NativeProcessProtocol &process, bool &had_any);
+
PacketResult Handle_qfThreadInfo(StringExtractorGDBRemote &packet);
PacketResult Handle_qsThreadInfo(StringExtractorGDBRemote &packet);
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1997,38 +1997,46 @@
return SendPacketNoLock(response.GetString());
}
-GDBRemoteCommunication::PacketResult
-GDBRemoteCommunicationServerLLGS::Handle_qfThreadInfo(
-StringExtractorGDBRemote &packet) {
+void GDBRemoteCommunicationServerLLGS::AddProcessThreads(
+StreamGDBRemote &response, NativeProcessProtocol &process, bool &had_any) {
Log *log = GetLog(LLDBLog::Thread);
-
[Lldb-commits] [PATCH] D128152: [lldb] [llgs] Support multiprocess in qfThreadInfo
mgorny marked an inline comment as done.
mgorny added inline comments.
Comment at:
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:1967
+
+ if (multiprocess) {
+for (auto &pid_ptr : m_debugged_processes)
labath wrote:
> without multiprocess extensions, we should never have more than one process,
> right? Could we just unconditionally use the multiprocess loop here (perhaps
> with an `assert(m_debugged_processes.size() == 1 || multiprocess)`) ?
Yes, that makes sense. We enable fork & vfork only if multiprocess is
supported, so that shouldn't happen unless we deal with broken Process plugin.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D128152/new/
https://reviews.llvm.org/D128152
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D128152: [lldb] [llgs] Support multiprocess in qfThreadInfo
labath accepted this revision.
labath added inline comments.
This revision is now accepted and ready to land.
Comment at:
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:1967
+
+ if (multiprocess) {
+for (auto &pid_ptr : m_debugged_processes)
without multiprocess extensions, we should never have more than one process,
right? Could we just unconditionally use the multiprocess loop here (perhaps
with an `assert(m_debugged_processes.size() == 1 || multiprocess)`) ?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D128152/new/
https://reviews.llvm.org/D128152
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D128152: [lldb] [llgs] Support multiprocess in qfThreadInfo
mgorny created this revision.
mgorny added reviewers: labath, krytarowski, emaste, jingham.
Herald added a subscriber: arichardson.
Herald added a project: All.
mgorny requested review of this revision.
Update the `qfThreadInfo` handler to report threads of all debugged
processes and include PIDs when in multiprocess mode.
Sponsored by: The FreeBSD Foundation
https://reviews.llvm.org/D128152
Files:
lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
Index: lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
===
--- lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
+++ lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
@@ -554,6 +554,66 @@
], True)
self.expect_gdbremote_sequence()
+@add_test_categories(["fork"])
+def test_threadinfo(self):
+self.build()
+self.prep_debug_monitor_and_inferior(
+inferior_args=["fork",
+ "thread:new",
+ "trap",
+ ])
+self.add_qSupported_packets(["multiprocess+",
+ "fork-events+"])
+ret = self.expect_gdbremote_sequence()
+self.assertIn("fork-events+", ret["qSupported_response"])
+self.reset_test_sequence()
+
+# continue and expect fork
+self.test_sequence.add_log_lines([
+"read packet: $c#00",
+{"direction": "send", "regex": self.fork_regex.format("fork"),
+ "capture": self.fork_capture},
+], True)
+self.add_threadinfo_collection_packets()
+ret = self.expect_gdbremote_sequence()
+pidtids = [
+(ret["parent_pid"], ret["parent_tid"]),
+(ret["child_pid"], ret["child_tid"]),
+]
+prev_pidtids = set(self.parse_threadinfo_packets(ret))
+self.assertEqual(prev_pidtids,
+ frozenset((int(pid, 16), int(tid, 16))
+ for pid, tid in pidtids))
+self.reset_test_sequence()
+
+for pidtid in pidtids:
+self.test_sequence.add_log_lines(
+["read packet: $Hcp{}.{}#00".format(*pidtid),
+ "send packet: $OK#00",
+ "read packet: $c#00",
+ {"direction": "send",
+ "regex": "^[$]T05thread:p{}.{}.*".format(*pidtid),
+ },
+ ], True)
+self.add_threadinfo_collection_packets()
+ret = self.expect_gdbremote_sequence()
+self.reset_test_sequence()
+new_pidtids = set(self.parse_threadinfo_packets(ret))
+added_pidtid = new_pidtids - prev_pidtids
+prev_pidtids = new_pidtids
+
+# verify that we've got exactly one new thread, and that
+# the PID matches
+self.assertEqual(len(added_pidtid), 1)
+self.assertEqual(added_pidtid.pop()[0], int(pidtid[0], 16))
+
+for pidtid in new_pidtids:
+self.test_sequence.add_log_lines(
+["read packet: $Hgp{:x}.{:x}#00".format(*pidtid),
+ "send packet: $OK#00",
+ ], True)
+self.expect_gdbremote_sequence()
+
@add_test_categories(["fork"])
def test_memory_read_write(self):
self.build()
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1930,38 +1930,48 @@
return SendPacketNoLock(response.GetString());
}
-GDBRemoteCommunication::PacketResult
-GDBRemoteCommunicationServerLLGS::Handle_qfThreadInfo(
-StringExtractorGDBRemote &packet) {
+static void AddProcessThreads(StreamGDBRemote &response,
+ NativeProcessProtocol &process, bool &had_any,
+ bool include_pid) {
Log *log = GetLog(LLDBLog::Thread);
- // Fail if we don't have a current process.
- if (!m_current_process ||
- (m_current_process->GetID() == LLDB_INVALID_PROCESS_ID)) {
-LLDB_LOG(log, "no process ({0}), returning OK",
- m_current_process ? "invalid process id"
- : "null m_current_process");
-return SendOKResponse();
- }
-
- StreamGDBRemote response;
- response.PutChar('m');
+ lldb::pid_t pid = process.GetID();
+ if (pid == LLDB_INVALID_PROCESS_ID)
+return;
- LLDB_LOG(log, "starting thread iteration");
+ LLDB_LOG(log, "iterating over threads of process {0}", process.GetID());
NativeThreadProtocol *thread;
uint32_t thread_index;
- for (thread_index = 0,
- thread = m_
