Fix a bug where the bitwise-not'ed bitset was accidently being used

[lanza]

Summary

A set of event_bits are requested to sing up to listen to and the
event_bits of the registered broadcasters are compared to see whether
they offer it. However, a mistaken ~ was added which caused the
inverse functionality to work.

This bug was missed up until now because the lldb_private::Debugger
registers it's listeners before the broadcasters are registered and
thus this check is only ever made when you are, e.g. using the SB API.

[clayborg]

A unit test would be nice so we catch future issues.

[lanza]

@clayborg Actually after going through the implementation, I might have been mistaken. Is the intent of the BroadcasterManager to restrict each Broadcaster to only emit each event to one listener? e.g. this available_bits value is the mask of events that currently aren't being listened to anded with the bits requested.

I was hoping to register a listener to communicate to a vim plugin to update the current file & line while still using the lldb CLI tool. But it seems this functionality prevents double listeners.

[clayborg]

In D59532#1440445, @lanza wrote:

@clayborg Actually after going through the implementation, I might have been mistaken. Is the intent of the BroadcasterManager to restrict each Broadcaster to only emit each event to one listener? e.g. this available_bits value is the mask of events that currently aren't being listened to anded with the bits requested.

I was hoping to register a listener to communicate to a vim plugin to update the current file & line while still using the lldb CLI tool. But it seems this functionality prevents double listeners.

I believe that this is correct. Some events are designed to only be forwarded to one listener. We could allow each broadcaster to define which events are ok to multi-cast, but one of the events that is sensitive to this is the process state listener. One other option would be to use the "target stop-hook add" command to add a command to execute after each public stop? FYI: there are public and private stops when running the program, the events get generated for both, but only public stops get delivered to the listener of the process state change. The target stop-hook command can do something each time we stop in the UI. You could run a custom python command in the target stop-hook that could pass along the info. Not sure what happens when you just switch between threads/frames though without getting a new stop?

[lanza]

I believe that this is correct. Some events are designed to only be forwarded to one listener. We could allow each broadcaster to define which events are ok to multi-cast, but one of the events that is sensitive to this is the process state listener. One other option would be to use the "target stop-hook add" command to add a command to execute after each public stop? FYI: there are public and private stops when running the program, the events get generated for both, but only public stops get delivered to the listener of the process state change. The target stop-hook command can do something each time we stop in the UI. You could run a custom python command in the target stop-hook that could pass along the info. Not sure what happens when you just switch between threads/frames though without getting a new stop?

Got ya. And the stop hook idea seems like it'll work perfectly. Thanks for the hint, Greg!!

source/Utility/Broadcaster.cpp

uint32_t BroadcasterManager::RegisterListenerForEvents(
 
   collection::iterator iter = m_event_map.begin(), end_iter = m_event_map.end();
   uint32_t available_bits = event_spec.GetEventBits();
 
   while (iter != end_iter &&
          (iter = find_if(iter, end_iter,
                          BroadcasterClassMatches(
                              event_spec.GetBroadcasterClass()))) != end_iter) {
-    available_bits &= ~((*iter).first.GetEventBits());
+    available_bits &= (*iter).first.GetEventBits();
     iter++;
   }
 
   if (available_bits != 0) {
     m_event_map.insert(event_listener_key(
         BroadcastEventSpec(event_spec.GetBroadcasterClass(), available_bits),
         listener_sp));
     m_listeners.insert(listener_sp);