Hi Jeffrey, Can you expand on your use cases here?
I think it's generally sufficient to set a breakpoint in the thread main that you'd like to stop on. Just because Linux/Windows surfaces these events doesn't necessarily mean they're useful. =) Anyway, please share your thoughts. Sincerely, Vince On Mon, Aug 3, 2015 at 2:50 PM, Jim Ingham <jing...@apple.com> wrote: > 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 >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
