This is an archive of the discontinued LLVM Phabricator instance.

[lldb] [gdb-remote] Initial support for multiple ContinueDelegates
Needs ReviewPublic

Authored by mgorny on Aug 13 2022, 6:52 AM.

Details

Summary

Introduce the initial support for handling multiple ContinueDelegates
in GDBRemoteClientBase::SendContinuePacketAndWaitForResponse(). This
is the first step towards moving to a shared asynchronous thread serving
multiple ProcessGDBRemote instances.

The final goal is that every stop response will be passed through all
ContinueDelegates, and every delegate will decide whether it is
applicable to its process. The additional handled parameter is used
to indicate that the correct delegate has been found and no further
delegates need to be invoked.

The next step is going to involve decoupling the async thread from
ProcessGDBRemote itself, and moving all the logic responsible for
updating the process status into ContinueDelegate API.

Sponsored by: The FreeBSD Foundation

Diff Detail

Event Timeline

mgorny created this revision.Aug 13 2022, 6:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 13 2022, 6:52 AM
Herald added a subscriber: arichardson. · View Herald Transcript
mgorny requested review of this revision.Aug 13 2022, 6:52 AM

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?

lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp
134–140

It would be nice to have a utility function for this loop (opportunity to play with templates and/or member function pointers).

lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h
23

Why not just make this a regular return value?

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?

Specifically about the O packets, I've been thinking that it doesn't really make any difference which process receives them — after all, they will be printed all the same, won't they?

lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h
23

I've figured out an explicit variable makes its purpose clearer, rather than arbitrary return true/false.

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?

Specifically about the O packets, I've been thinking that it doesn't really make any difference which process receives them — after all, they will be printed all the same, won't they?

Not exactly. That output gets routed through process-specific (SB)Process:GetSTDOUT functions. Of course, if you're using the command line, then all of these outputs will funnel into the lldb terminal anyway, but a scripting/gui user might be doing something different. I guess one of the goals of a future larger SB API redesign could be refactor this such that it is clear that forked processes will share the same terminal/stdout..

lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h
23

Maybe sometimes, but I don't think that's the case here. I mean, if you think this is particularly ambiguous, you could make a {handled, not_handled} enum and return that.