[Lldb-commits] [PATCH] D131837: [lldb] [gdb-remote] Initial support for multiple ContinueDelegates

Pavel Labath via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Thu Aug 18 11:43:16 PDT 2022


labath added a comment.

This sort of makes sense to me, but it's not clear to me how is this selection logic going to apply to packets other than stop-replies. All of the forked processes are going to share the same pty, so it's going to be literally impossible to distinguish the `O` packets, for instance. I'm wondering if it would make sense to split this interface into two, and have just one "preferred" recipient of `O` packets (and possibly others as well -- as we have no plans for supporting them right now), and have a separate list of recipients who would do things with the stop replies?



================
Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp:134-140
+      for (auto delegate : delegates) {
+        bool handled = false;
+        delegate->HandleAsyncStructuredDataPacket(response.GetStringRef(),
+                                                  handled);
+        if (handled)
+          break;
+      }
----------------
It would be nice to have a utility function for this loop (opportunity to play with templates and/or member function pointers).


================
Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h:23
     virtual ~ContinueDelegate();
-    virtual void HandleAsyncStdout(llvm::StringRef out) = 0;
-    virtual void HandleAsyncMisc(llvm::StringRef data) = 0;
-    virtual void HandleStopReply() = 0;
+    virtual void HandleAsyncStdout(llvm::StringRef out, bool &handled) = 0;
+    virtual void HandleAsyncMisc(llvm::StringRef data, bool &handled) = 0;
----------------
Why not just make this a regular return value?


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

https://reviews.llvm.org/D131837



More information about the lldb-commits mailing list