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

Greg Clayton via lldb-dev lldb-dev at lists.llvm.org
Tue Oct 25 11:15:32 PDT 2016


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



More information about the lldb-dev mailing list