I will need to dig into the code again (it's been almost a year, so I don't remember details)!
>From what I remember, some of the Windows-specific things were: - 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") - As mentioned earlier, causing a process to break was actually launching another "control" thread inside the debugged Windows process, which would do the int3. - The way multiple threads could hit the same breakpoint (probably partly due to having to go back to main debugger thread) needed special handling ( https://github.com/xen2/lldb/commit/515956244784a9162183a6135068e893ba994532#diff-826417f27b16bb5b36023b7e6cbc6829R474 ) 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. 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. On 15 November 2014 09:36, Zachary Turner <[email protected]> wrote: > Yea that's more or less what I'm planning to do. Thanks! > > > On Fri Nov 14 2014 at 4:31:19 PM Greg Clayton <[email protected]> wrote: > >> You could probably maintain these: >> >> ThreadList newWindowsThreads; >> ThreadList deadWindowsThreads; >> >> As just vectors of your handles: >> >> std::vector<HANDLE> newWindowsThreadHandles; >> std::vector<HANDLE> deadWindowsThreadHandles; >> >> Then in: >> >> bool >> ProcessWindows::UpdateThreadList (ThreadList &old_thread_list, >> ThreadList &new_thread_list) >> >> 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... >> >> 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... >> >> > On Nov 14, 2014, at 4:20 PM, Zachary Turner <[email protected]> wrote: >> > >> > >> > >> > On Fri Nov 14 2014 at 4:13:17 PM <[email protected]> wrote: >> > >> > > 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. >> > >> > You get one view of the thread if you catch the event but another if >> you enumerate them when stopped? That's awkward. >> > >> > 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. >> > >> > Thanks for the additional explanations >> > >> > >> >> > _______________________________________________ > 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
