[lldb-dev] Generating an event when calling SBThread::SetSelectedFrame and SBProcess::SetSelectedThreadByID

[Bogdan Hopulele via lldb-dev]

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

-----Original Message-----
From: Greg Clayton [mailto:gclayton at apple.com]
Sent: Tuesday, October 25, 2016 9:16 PM
To: Jim Ingham <jingham at apple.com>
Cc: Bogdan Hopulele <bogdan.hopulele at ni.com>; lldb-dev at lists.llvm.org
Subject: Re: [lldb-dev] Generating an event when calling SBThread::SetSelectedFrame and SBProcess::SetSelectedThreadByID

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

> On Oct 25, 2016, at 9:38 AM, Jim Ingham via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>
> 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
>
>
>> On Oct 25, 2016, at 1:42 AM, Bogdan Hopulele via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>
>> 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
>> National Instruments Romania S.R.L.
>> ------------------------------------------------------
>> B-dul 21 Decembrie 1989, nr. 77, A2
>> Cluj-Napoca 400604, Romania
>> C.I.F.: RO17961616 | O.R.C.: J12/3337/2005
>> Telefon: +40 264 406428 | Fax: +40 264 406429
>> E-mail: office.cluj at ni.com
>> Web: romania.ni.com
>>
>> Vanzari si suport tehnic:
>> Telefon gratuit : 0800 070071
>> E-mail vanzari: ni.romania at ni.com
>> E-mail suport tehnic: techsupport at ni.com _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

National Instruments Romania S.R.L.
------------------------------------------------------
B-dul 21 Decembrie 1989, nr. 77, A2
Cluj-Napoca 400604, Romania
C.I.F.: RO17961616 | O.R.C.: J12/3337/2005
Telefon: +40 264 406428 | Fax: +40 264 406429
E-mail: office.cluj at ni.com
Web: romania.ni.com

Vanzari si suport tehnic:
Telefon gratuit : 0800 070071
E-mail vanzari: ni.romania at ni.com
E-mail suport tehnic: techsupport at ni.com