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@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@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.c...@ni.com >> Web: romania.ni.com >> >> Vanzari si suport tehnic: >> Telefon gratuit : 0800 070071 >> E-mail vanzari: ni.roma...@ni.com >> E-mail suport tehnic: techsupp...@ni.com >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
