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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
