[Lldb-commits] [PATCH] D126614: [lldb] [gdb-remote] Client support for using the non-stop protocol

Wed Jul 27 06:50:36 PDT 2022

labath added a comment.

Sorry about the delay. I've been putting this off because it's complicated, although that's a lousy excuse. The gist of it is that I don't think that the existing setup of the "async threads" and "continue locks" is going to work in this new world. The reason it has worked until now is because the async thread has been exclusively reading packets, and the only thing that the other threads could do is to write a special single-character "packet" which has no response. With this patch neither of those things is true anymore -- the async thread sends a bunch of notification packets, and vCtrlC packet sent by other threads is a regular packet that we should get a response to. Currently, I don't see anything preventing the two threads from talking over each other.

I think we need to do something about this. *One* way to do it (I'm sure there are others) is to move all the (interruption-related) communication into the async thread. Instead of sending the interrupt (both ^C and vCtrlC) packet from the interrupting thread directly, we would instead signal the async thread in some way, and let it do the interruption for us. The communication will be single threaded then, and it should be easier to maintain the protocol integrity. We might be able to reuse/repurpose the `InterruptRead` functionality to achieve this. (It's possible that won't work on windows -- I should be able to help if that's the case.)

================
Comment at: lldb/test/API/functionalities/gdb_remote_client/TestNonStop.py:80-82
+            self.runCmd(
+                "settings set plugin.process.gdb-remote.use-non-stop-protocol "
+                "false"))
----------------
I don't think this is necessary anymore. These days we should be reseting all settings before each test.

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

https://reviews.llvm.org/D126614