We need need a tristate dingus: unavailable, free, and not free... On Windows it sounds like collecting thread state is done as a matter of course when debugging. On Linux, IIUC, you have to manually attach to threads running in the program you are debugging, so though this info isn't free we have to pay the cost for it anyway, so from the user's perspective it is. On OS X I could do a pretty good job of thread creation, but it would mean interfering with the program in ways I would not have to ordinarily do. So right now it isn't available, but I could pretty easily make it happen, but it would not be free. Thread destruction, as I said, will be harder on OS X.
If the info is free, there's no reason not to send the events, since if there are no listeners, the broadcasters don't really do any work. So for free systems, the default should be to broadcast events. But on platforms where the data is available but not free the default setting for broadcasting should be off. And of course for platforms where it is unavailable, you won't be able to set it on. Jim > On Aug 1, 2015, at 3:21 PM, Zachary Turner <ztur...@google.com> wrote: > > We get these notifications in the windows process plugin. So if this is > something you need and you are using Windows, perhaps you could do as Jim > suggests by making the setting, but then only make it possible to turn the > setting on for platforms that support this. Note that on Windows, you don't > need to interfere with the process to get these events, because the OS gives > the events to you, and when it gives them to you the process is already > stopped for a very short amount of time. So this could "just work" on > Windows, meaning that the setting could be on by default (and then perhaps > off by default on other platforms) > > On Sat, Aug 1, 2015 at 1:35 PM Jeffrey Tan <jeffrey.fu...@gmail.com> wrote: > Came from a Windows world thought this is trivial to do. Thanks for the > explanation. > > On Fri, Jul 31, 2015 at 4:34 PM, Jim Ingham <jing...@apple.com> wrote: > lldb doesn't attempt to generate thread creation & destruction events at > present. If it did there would be a "threadCreated" event on the process, > but as you see there isn't... > > There was some discussion about this a little while ago on the list. IMHBSEO > the debugger should interfere with the running of a program as little as > possible when the target is just running flat out. So I wouldn't want lldb > to watch thread creation and destruction by default, since you will end up > starting and stopping the target much more often for information that in > general you don't want to see. > > But it would be fine to add a setting that you could turn on in lldb to try > to catch thread create/destroy. For extra credit, you could flip this on when > somebody signs up for the thread creation events we would vend. > > Anyway, IIUC gathering these events would be easy to do on Linux, since you > already have to be notified of new thread creation so you can attach to them. > > On OS X it would be trickier. There is no kernel level notification of > thread creation or destruction. You could get thread creation by breaking on > the couple of functions OS X always uses to start up new threads. Getting > destruction would be trickier since you'd have put a breakpoint in the thread > create function on the return from the thread body function. That would > probably be easy to tell by eyeballing the function's disassembly, but might > be harder to determine programmatically. > > Feel free to file a bug or even better provide a patch if this is something > you really need. > > Jim > > > On Jul 31, 2015, at 3:13 PM, Jeffrey Tan <jeffrey.fu...@gmail.com> wrote: > > > > How to receive thread create/destroy events from LLDB? I did not find a > > broadcast bit from SBTarget or SBProcess or SBThread. I have enabled both > > SBProcess.eBroadcastBitStateChanged and > > SBTarget.eBroadcastBitBreakpointChanged, but still did not retrieve any > > thread create/destroy event via SBThread.EventIsThreadEvent(). > > > > I know I can query for all threads while process is paused but thread can > > be create/destroy in run mode so it is important/useful for debugger client > > to receive this kind of notification. > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
