[lldb-dev] Process plugin implementation with multiple threads

[Virgile Bello]

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 <zturner at google.com> 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 <gclayton at apple.com> 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 <zturner at google.com> wrote:
>> >
>> >
>> >
>> > 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.
>> >
>> > 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
> 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/20141115/76d57f6a/attachment.html>