[lldb-dev] Process plugin implementation with multiple threads

[Zachary Turner]

On Fri Nov 14 2014 at 4:13:17 PM <jingham at apple.com> wrote:

>
> > On Nov 14, 2014, at 3:46 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > It's possible, but Windows gives us a handle to the thread which has all
> privileges associated with it (in other words we can use it for just about
> anything), so it's considered better to use the handle windows gives us. At
> the very least we'd want to queue up all the incoming event notifications
> that we get from this loop, and then use it to update the state when
> someone stops.
>
> You get one view of the thread if you catch the event but another if you
> enumerate them when stopped?  That's awkward.
>
> >
> > Just to be certain, when you and Greg refer to "when someone has
> stopped", I assume you are referring to a public stop, i.e. someone has to
> enter a command to resume the debugger?
> >
> > I was wondering why my RefreshStateAfterStop override was never being
> called, I'm guessing now that it's because I was only updating the private
> state, and this only gets called on a public stop.
> >
> >
>
> That's not quite what happens, I don't know if what actually happens also
> explains what you are seeing, but this is how this bit of logic works:
>
> When the private state gets changed we generate an event and put it on the
> public event queue.  Then we call "Process::ShouldBroadcastEvent", to
> decide whether to deliver the event to the listener on the process
> broadcaster. RefreshStateAfterStop gets called in ShouldBroadcastEvent,
> just before we go into the decision loop about whether to broadcast a
> stopped event or not.  The event might not be broadcast, for instance it
> might get consumed by the thread plans because the stop was just one part
> of their larger designs.  If we do decide to broadcast the event, it gets
> put on the event queue.  Then when the event gets consumed by the process
> listener THAT'S when the public state finally gets updated.  Note, even if
> we broadcast an event we might not change the state, since one of the
> StopInfo actions might have restarted the process (e.g. a breakpoint
> command).  In that case we don't change the public state, but just mark the
> event as a stopped event with the restarted flag set.
>
> This little dance is kind of obnoxious, but it is required so that the
> thread plans can do their jobs without spamming the public event consumer
> with all sorts of spurious stops and starts, and also so that the state is
> kept in sync with the last event you've consumed.  After all, if your
> process ran and stopped again right away, and you had consumed the
> "running" event, but hadn't consumed the "stopped" event, it would be kind
> of disconcerting for the state to be "stopped"...
>
>

Digging up this old thread a little bit.  So on Windows now I can launch a
process with -s to stop at the initial breakpoint, and when I do this I can
print register values, stack frames, and lots of other things.

But RefreshStateAfterStop isn't being called for the initial stop.  This is
where I've put all my code to update the StopInfo of the various threads,
so currently for the initial breakpoint I've got no way to tell the threads
why they're stopped.

There's a comment in Process::Launch() that seems to justify this, which
says this:

// Note, the stop event was consumed above, but not handled. This was done
// to give DidLaunch a chance to run. The target is either stopped or
crashed.
// Directly set the state.  This is done to prevent a stop message with a
bunch
// of spurious output on thread status, as well as not pop a
ProcessIOHandler.

But still, this is a real stop that will cause the debugger to break.  Is
it a bug that RefreshStateAfterStop isn't being called for this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141124/a0bbeeb6/attachment.html>