> On Nov 14, 2014, at 3:46 PM, Zachary Turner <[email protected]> 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.
>
> 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?
No just a private stop. You should _not_ be changing the process state to
stopped and running again (via Process::SetPrivateState()) for thread creation
or thread death, only for stops where an existing thread stops for some reason
(trace (single step), breakpoint, exception, etc). The private state thread
will move the thread plans along for private stops, which agains are only
actual stops where the process stops due to a existing thread (not a new or
dying thread) stopping for a reason. These thread creation events should be
suppressed from the private state thread and only handled for your own
purposed. You also do not want to be updating the thread list as you are
running (the one in Process::GetThreadList()), so you should keep your own
ThreadList object within the windows event loop that only your windows event
will update. Later when a stop gets propagated to the private state of the
process, it will call:
virtual bool
UpdateThreadList (ThreadList &old_thread_list, ThreadList &new_thread_list)
= 0;
And you can merge your private copy of your ThreadList into new_thread_list as
needed. You should be doing something like:
ThreadList newWindowsThreads;
ThreadList deadWindowsThreads;
while (WaitForDebugEvent(&event)) // Block until something happens in the
process
{
if (event is thread creation)
{
newWindowsThreads.Append(new thread)
}
else if (event is thread death)
{
deadWindowsThreads.Append(...)
}
// Windows stopped the process for us automatically. Do something with the
event
ContinueDebugEvent(&event); // Resume the process
}
Then in your
bool
ProcessWindows::UpdateThreadList (ThreadList &old_thread_list, ThreadList
&new_thread_list)
{
// Append any threads from old_thread_list into new_thread_list if they
are still alive by checking if any of them are in deadWindowsThreads and only
adding them if they aren't in the list
// Append all threads from newWindowsThreads into new_thread_list
}
> 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.
Yes this seems to be for public stops only. ProcessWindows::UpdateThreadList()
isn't only for public stops, it is used in private stops as well.
>
>
> On Fri Nov 14 2014 at 3:26:47 PM <[email protected]> wrote:
> Is there a way to ask Windows "give me all the threads for this process"? If
> so, the path of least resistance would be to ignore the Thread Created events
> in this loop, and then only generate the thread list on demand when someone
> has stopped.
>
> At some point we'll want to do keep alive debugging and then we'll have to
> handle posting interesting events while the process is still running. But I
> don't want to do that piecemeal.
>
> For now, putting threads in the thread list while the debugger is running
> from both the private & public state's perspective does no good, and putting
> them in between a stop & an immediate continue doesn't do anybody any good
> either. You're just making your plugin more fragile.
>
> Jim
>
>
> > On Nov 14, 2014, at 3:08 PM, Zachary Turner <[email protected]> wrote:
> >
> > The way Windows debug notifications work is like this:
> >
> > while (WaitForDebugEvent(&event)) // Block until something happens in the
> > process
> > {
> > // Windows stopped the process for us automatically. Do something with
> > the event
> >
> > ContinueDebugEvent(&event); // Resume the process
> > }
> >
> > After WaitForDebugEvent and before I call ContinueDebugEvent, the event
> > might say that a new thread was created. So at this point I'd like to
> > update the thread list. The process is actually stopped here, but it
> > shouldn't appear so to the user. So at the beginning I tell LLDB the
> > process is stopped -- SetPrivateState(eStateStopped), and at the end I tell
> > it that it's running again -- SetPrivateState(eStateRunning).
> >
> > However, this code is still running on a different from what LLDB is going
> > to invoke methods on the plugin. RefreshStateAfterStop, DoResume, etc are
> > all going to be running on a different thread from this loop. The code is
> > simpler if I can just stick the new thread in the ThreadList (or whatever
> > other state needs updating if it's not thread related) right here from this
> > thread. Alternatively, when I set the state to eStateStopped presumably
> > that will trigger LLDB to call RefreshStateAfterStop() from the other
> > thread. I can also modify the state then, it just requiers a little extra
> > work as I have to do some synchronization and marshalling / storage of the
> > event parameters.
> >
> > On Fri Nov 14 2014 at 2:53:35 PM Greg Clayton <[email protected]> wrote:
> >
> > > On Nov 14, 2014, at 10:15 AM, Zachary Turner <[email protected]> wrote:
> > >
> > > Windows doesn't need to do anything special for each thread as it is
> > > created. Only need to update the thread list in the Process object as far
> > > as we're concerned, but that's it.
> > >
> > > The main thing I'm worried about is that the Process object itself runs a
> > > couple of threads in the background (the private state thread, for
> > > example), so I was worried about possible race conditions when modifying
> > > state asynchronously (i.e. from my debugger thread).
> >
> > What state needs to be updated asynchronously? You shouldn't be touching
> > the thread list (no need to update it, you should be able to update it on
> > demand each time you actually stop right?) at all until you have a valid
> > stop reason and then the process will update the threads itself when and if
> > it needs them.
> > _______________________________________________
> > lldb-dev mailing list
> > [email protected]
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
