This is an archive of the discontinued LLVM Phabricator instance.

[lldb/Utility] Add opt-in shadow mode to event listeners
ClosedPublic

Authored by mib on Apr 14 2023, 5:01 PM.

Details

Summary

This patch augments lldb's event listeners with a new shadow mode.

As the name suggests, this mode allows events to be copied to an
additional listener to perform event monitoring, without interferring
with the event life cycle.

One of our use case for this, is to be able to listen to public process
events while making sure the events will still be delivered to the
default process listener (the debugger listener in most cases).

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

Diff Detail

Event Timeline

mib created this revision.Apr 14 2023, 5:01 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 14 2023, 5:01 PM
Herald added a subscriber: emaste. · View Herald Transcript
mib requested review of this revision.Apr 14 2023, 5:01 PM
bulbazord added inline comments.Apr 17 2023, 12:48 PM
lldb/include/lldb/Utility/Broadcaster.h
520–522

It looks like Broadcaster can have multiple listeners. Do we want multiple passthrough listeners as well? If not, why only one?

lldb/source/API/SBAttachInfo.cpp
260

GetPassthroughListener can return nullptr. I think you want to take advantage of the protected SBListener(const ListenerSP &) constructor here but I think that if GetPassthroughListener returns nullptr you'll end up calling the constructor SBListener(const char *). I don't think this is what you want.

lldb/source/API/SBLaunchInfo.cpp
395

Same issue as SBAttachInfo::GetPassthroughListener

I find "passthrough" somewhat confusing in this context. When using a listener in this new mode, where does the event go after it has pass trough this event listener? Maybe my understanding of how the event listeners is incomplete, but I was under the impression that normally there's a single listener for a certain kind of event. IIUC, in this new mode, you can have multiple listeners, where you can set one (or as Alex pointed out, possibly more) listeners that can observe events but not necessary deal with them. If that's an accurate description of the interactions, then it seems like there's more of a one-to-many relationship between events and listeners rather than what passthrough implies. I think a better name would be something like "passive listener" or "non-handling" listener or something.

mib marked 2 inline comments as done.Apr 20 2023, 2:49 PM

I find "passthrough" somewhat confusing in this context. When using a listener in this new mode, where does the event go after it has pass trough this event listener? Maybe my understanding of how the event listeners is incomplete, but I was under the impression that normally there's a single listener for a certain kind of event. IIUC, in this new mode, you can have multiple listeners, where you can set one (or as Alex pointed out, possibly more) listeners that can observe events but not necessary deal with them. If that's an accurate description of the interactions, then it seems like there's more of a one-to-many relationship between events and listeners rather than what passthrough implies. I think a better name would be something like "passive listener" or "non-handling" listener or something.

@JDevlieghere You could also have multiple listeners for a certain type of event, but events would be considered "handled" only when they're popped from the listener passed during the process creation (or the debugger listener if no listener is provided in the {launch,attach}info). The idea behind passthrough listener was to have a side channel where all the events would be funneled to, that would never interfere with the default listener and therefore not change the process execution behavior. If you really feel strongly about the "passthrough" name, I can rename it to whatever you like but I feel like it's pretty self explanatory.

lldb/include/lldb/Utility/Broadcaster.h
520–522

That's a very good point. When I implemented this, I was thinking that the passthrough listener would act as a funnel for all the events. But having multiple passthrough listener could potentially allow the user to do some filtering on the event. @jingham what do you think ?

mib updated this revision to Diff 515498.Apr 20 2023, 2:54 PM

Fix issue when returning a non-initialized passthrough listener from the SBAPI

I find "passthrough" somewhat confusing in this context. When using a listener in this new mode, where does the event go after it has pass trough this event listener? Maybe my understanding of how the event listeners is incomplete, but I was under the impression that normally there's a single listener for a certain kind of event. IIUC, in this new mode, you can have multiple listeners, where you can set one (or as Alex pointed out, possibly more) listeners that can observe events but not necessary deal with them. If that's an accurate description of the interactions, then it seems like there's more of a one-to-many relationship between events and listeners rather than what passthrough implies. I think a better name would be something like "passive listener" or "non-handling" listener or something.

@JDevlieghere You could also have multiple listeners for a certain type of event, but events would be considered "handled" only when they're popped from the listener passed during the process creation (or the debugger listener if no listener is provided in the {launch,attach}info). The idea behind passthrough listener was to have a side channel where all the events would be funneled to, that would never interfere with the default listener and therefore not change the process execution behavior. If you really feel strongly about the "passthrough" name, I can rename it to whatever you like but I feel like it's pretty self explanatory.

To me, passthrough means something sitting in-between something else. It's still not clear to me what the passthrough listener is sitting in between. It sounds like it's meant to be a side channel, so maybe shadow listener would be a better name? I don't care so much about the name per se but rather about making it obvious what it does.

mib updated this revision to Diff 515956.Apr 21 2023, 4:59 PM
mib marked an inline comment as done.
mib retitled this revision from [lldb/Utility] Add opt-in passthrough mode to event listeners to [lldb/Utility] Add opt-in shadow mode to event listeners.
mib edited the summary of this revision. (Show Details)

"Shadow Listener" it is @JDevlieghere

mib updated this revision to Diff 515959.Apr 21 2023, 5:06 PM

More renaming and reformat

mib updated this revision to Diff 515960.Apr 21 2023, 5:09 PM

fix typo

This revision is now accepted and ready to land.Apr 24 2023, 12:40 PM
This revision was automatically updated to reflect the committed changes.