Note: All of this is Windows specific, and I'm kind of the only person working on this. So I'm not really sure who should review this. I'm adding Jim and Greg, but feel free to ignore if you don't care about this. Also adding a few Windows people from here, although if ultimately nobody cares enough to review this, since it is entirely Windows specific, I will just go in with it.
This implements ProcessWindows::DoLaunch() in such a way that a connection is created between LLDB and the Windows kernel that allows us to obtain notifications of interesting things that happen in an inferior process on Windows.
Put another way, this implements the "ptrace" part of debugging for Windows processes.
This is complicated by some technical restrictions surrounding how processes are monitored for debug events on Windows. Specifically:
- LLDB's generic process launching code expects that launching a process and monitoring a process can be treated as two distinct operations. It is possible to split this into two separate operations on Windows, but the code would be very cumbersome, and it is much simpler to allow the monitoring and launching to occur as one high level operation. This is largely because:
- In Windows, the core debug loop (i.e. the ptrace equivalent) must happen on the same thread that spawns the process, and this is a loop that ultimately blocks until the process dies. Therefore, we cannot spawn the inferior process on LLDB's main thread, which presents a complication for the design that LLDB currently uses which expects launching a process to be a synchronous operation, after which monitoring can begin.
The solution to these problems implemented here is for ProcessWindows to completely circumvent Host::LaunchProcess. When ProcessWindows is initialized at program startup, we create a single background thread. This background thread does two things:
a) Pump an application-specific message queue and wait for messages from the main thread that tell it to do things (e.g. launching processes, attaching to processes etc).
b) When we are actively debugging processes (as a result of messages received by step a described above), also pump Windows' message queue for events related to processes we're debugging.
We currently only understand one type of application specific message, which is that of launching a process, and we still do not correctly update LLDB's internal state so that it knows the process has been launched. But this should provide the framework for future operations to be implemented more easily.