[lldb-dev] Listening for thread create/destroy events in python LLDB

[Vince Harron]

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 <jingham at 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 <zturner at 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.fudan at 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 <jingham at 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.fudan at 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 at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150803/125c244e/attachment.html>