[lldb-dev] Process plugin implementation with multiple threads
virgile.bello at gmail.com
Fri Nov 14 19:42:44 PST 2014
I will need to dig into the code again (it's been almost a year, so I don't
>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
- 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 (
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:
>> 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>
>> > >
>> > > 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
>> > Thanks for the additional explanations
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev