This patch implements basic support for stopping at breakpoints
and resuming later. While a breakpoint is stopped at, LLDB will
cease to process events in the debug loop, effectively suspending
the process, and then resume later when ProcessWindows::DoResume
is called.
As a side effect, this also correctly handles the loader breakpoint
(i.e. the initial stop) so that LLDB goes through the correct state
sequence during the initial process launch.
llvm-svn: 221642
Originally the idea was that we would queue requests to a master
thread that would dispatch them to other slave threads each
responsible for debugging an individual process. This might make
some scenarios more scalable and responsive, but for now it seems
to be unwarranted complexity for no observable benefit.
llvm-svn: 221561
In the llgs world, ProcessWindows will eventually go away and
we'll implement a different protocol. This patch decouples
ProcessWindows from the core debug loop so that this transition
will not be more difficult than it needs to be.
llvm-svn: 221405
Renamed monitor -> driver, to make clear that the implementation here
is in no way related to that of other process plugins which have also
implemented classes with similar names such as DebugMonitor.
Also created a DebugEventHandler interface, which will be used by
implementors to get notified when debugging events happen in the
inferiors.
llvm-svn: 221322
When processes are launched for debugging on Windows now, LLDB
will detect changes such as DLL loads and unloads, breakpoints,
thread creation and deletion, etc.
These notifications are not yet propagated to LLDB in a way that
LLDB understands what is happening with the process. This only
picks up the notifications from the OS in a way that they can be
sent to LLDB with subsequent patches.
Reviewed by: Scott Graham
Differential Revision: http://reviews.llvm.org/D6037
llvm-svn: 221207
This implements Host::LaunchProcess for windows, and in doing so
does some minor refactor to move towards a more modular process
launching design.
The original motivation for this is that launching processes on
windows needs some very windows specific code, which would live
most appropriately in source/Host/windows somewhere. However,
there is already some common code that all platforms use when
launching a process before delegating to the platform specific
stuff, which lives in source/Host/common/Host.cpp which would
be nice to reuse without duplicating.
This commonality has been abstracted into MonitoringProcessLauncher,
a class which abstracts out the notion of launching a process using
an arbitrary algorithm, and then monitoring it for state changes.
The windows specific launching code lives in ProcessLauncherWindows,
and the posix specific launching code lives in ProcessLauncherPosix.
When launching a process MonitoringProcessLauncher is created, and
then an appropriate delegate launcher is created and given to the
MonitoringProcessLauncher.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5781
llvm-svn: 219731
FileAction was previously a nested class in ProcessLaunchInfo.
This led to some unfortunate style consequences, such as requiring
the AddPosixSpawnFileAction() funciton to be defined in the Target
layer, instead of the more appropriate Host layer. This patch
makes FileAction its own independent class in the Target layer,
and then moves AddPosixSpawnFileAction() into Host as a result.
Differential Revision: http://reviews.llvm.org/D4877
llvm-svn: 215649
This patch creates a simple ProcessWindows process plugin.
The only thing it knows how to do currently is create processes.
Differential Revision: http://reviews.llvm.org/D4681
llvm-svn: 214094
Zachary Turner