<div dir="ltr">I will need to dig into the code again (it's been almost a year, so I don't remember details)!<div><br></div><div>From what I remember, some of the Windows-specific things were:</div><div>- You could only launch and process most of debugging Windows API command from the thread where CreateProcess was done (let's call it the "Debugger control thread")</div><div>- As mentioned earlier, causing a process to break was actually launching another "control" thread inside the debugged Windows process, which would do the int3.</div><div>- The way multiple threads could hit the same breakpoint (probably partly due to having to go back to main debugger thread) needed special handling (<a href="https://github.com/xen2/lldb/commit/515956244784a9162183a6135068e893ba994532#diff-826417f27b16bb5b36023b7e6cbc6829R474">https://github.com/xen2/lldb/commit/515956244784a9162183a6135068e893ba994532#diff-826417f27b16bb5b36023b7e6cbc6829R474</a> )</div><div><br></div><div>I think I was passing message of thread creation/deletion instead of registering them immediately so that "state view" would be consistent from within this "Debugger control thread" and externally.</div><div>However, I was still learning LLDB architecture at the time (wasn't sure about what kind of invariant/state was expected from outside), so it might be not necessary.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 November 2014 09:36, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yea that's more or less what I'm planning to do.  Thanks!<div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote">On Fri Nov 14 2014 at 4:31:19 PM Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You could probably maintain these:<br>
<br>
ThreadList newWindowsThreads;<br>
ThreadList deadWindowsThreads;<br>
<br>
As just vectors of your handles:<br>
<br>
std::vector<HANDLE> newWindowsThreadHandles;<br>
std::vector<HANDLE> deadWindowsThreadHandles;<br>
<br>
Then in:<br>
<br>
bool<br>
ProcessWindows::<u></u>UpdateThreadList (ThreadList &old_thread_list, ThreadList &new_thread_list)<br>
<br>
You can search the old_thread_list and see if any of these have handles that are in deadWindowsThreadHandles and if so don't copy them over into new_thread_list, and if they aren't do copy them over. Then you would create new windows threads (subclasses of lldb_private::Thread) for all items in newWindowsThreadHandles...<br>
<br>
There is no need to create any lldb_private::Thread subclasses objects until you have a stop that might use them for debugger purposes as the thread might be created and also die before you stop, so you would want to remove any items from newWindowsThreadHandles that are in deadWindowsThreadHandles or remove dead threads from newWindowsThreadHandles without adding them to deadWindowsThreadHandles if they already exist in newWindowsThreadHandles before a stop comes along...<br>
<br>
> On Nov 14, 2014, at 4:20 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
><br>
><br>
> On Fri Nov 14 2014 at 4:13:17 PM <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
><br>
> > On Nov 14, 2014, at 3:46 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> ><br>
> > 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.<br>
><br>
> You get one view of the thread if you catch the event but another if you enumerate them when stopped?  That's awkward.<br>
><br>
> It's likely possible to get the same view of the thread, but there's no guarantee.  handles are funny things, and there's a huge amount of complexity and security checks that go on behind the scenes when you try to open a handle, so it's safer to just use the one that's been blessed by the OS.<br>
><br>
> Thanks for the additional explanations<br>
><br>
><br>
<br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div><br></div>