Generating an event when calling SBThread::SetSelectedFrame and SBProcess::SetSelectedThreadByID

Hi all,

Does anyone know how I can get LLDB to generate events when calling SBProcess::SetSelectedThreadByID?

SetSelectedThreadByID calls SetSelectedThreadByIndexID, but it doesn’t pass the notify parameter so it defaults to false in ThreadList.h . Same story for SBThread::SetSelectedFrame.

Why is the default set to false? The event shouldn’t be generated if there is no listener and if there is one then why not notify it? I’m also curious how Xcode manages to update its threads window when changing the selected thread from the console if no event gets generated.

2 solutions come to mind:

  1. Overload the public functions in order to expose the notify parameter (broadcast for the frame function).

  2. Change the default if there is no reason to have it set to false.

Thanks,

Bogdan

The SB API's in general don't send events about changing the things that they directly change. It seems awkward to say "Do X" and then have to field an event telling you that "X was done". And the return from the function generally tells you whether what you tried to do succeeded or not, so it is a redundant piece of information.

If you are trying to use the event system so that you can just listen to events to manage updates, regardless of who initiated the action, you probably want all the SB API's the perform actions that would generate events to do so. That makes it sound more like you want there to be a mode of the debugger where we pass notify->true for all the lldb_private API's that take it, rather than having to decide on a call-by-call basis. If you are going to do it that way you probably want this to be set at startup, since it doesn't seem like the sort of thing you want people to be able to change out from under you. Anyway, that seems cleaner to me.

BTW, the lldb command line commands DO send events when the selected thread/frame/etc. changes. That's necessary since a program driving lldb has no good way of knowing what the command line commands have done otherwise.

Jim

I agree with Jim here. If you are calling an API manually, I don't see a reason for a notification. A few ways to fix this:
1 - Add a SBBroadcaster to your code and then listen to it in your main event loop that is already listening to events. When you call SBProcess::SetSelectedThreadByID(), you also broadcast to your broadcaster.
2 - Add a argument to a new version of SBDebugger::Create() that is something like "notify_API_calls" which would get stored in the lldb_private::Debugger instance. Then change all appropriate API calls to grab this value from the debugger and use it so each call knows if it should notify.

Greg

I was updating the stack on eBroadcastBitSelectedFrameChanged event. This meant that on the event eBroadcastBitStateChanged (eStateStopped) I was setting the selected thread (even if it was the same one) and on eBroadcastBitThreadSelected I was setting the selected frame. I agree that when calling the API manually this is not really needed. It just seemed simpler at first.

I change my code to update the stack when doing an action that changed it, like switching the selected thread, instead of relying only on events.

Thanks for the clarifying,
Bogdan