summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/Windows
Commit message (Collapse)AuthorAgeFilesLines
...
* Some fixes for thread stepping on Windows.Zachary Turner2015-01-153-46/+48
| | | | | | | | | | | | | This hooks up the changes necessary to set the trap flag on the CPU and properly manage the process and thread's resume state and private state so that the ThreadPlan does its thing. Stepping still doesn't work as of this change, because there are some issues with stack frames where it doesn't update the thread's frame list correctly when it breaks inside of a function, but I will try to fix that separately. llvm-svn: 226221
* Only set the StopInfo on Windows if the stop is valid for this thread.Zachary Turner2015-01-141-7/+3
| | | | llvm-svn: 226054
* Fix a number of tests on Windows.Zachary Turner2015-01-141-1/+1
| | | | | | | These fix various issues with path handling and disable a few tests which use features of LLVM which are not yet supported on Windows. llvm-svn: 226042
* Remove a lock acquisition from ProcessWindows::OnExitProcess.Zachary Turner2015-01-061-11/+12
| | | | | | | | | | | | | This was causing a race condition where DoDestroy() would acquire the lock and then initiate a shutdown and then wait for it to complete. But part of the shutdown involved acquiring the same lock from a different thread. So the main thread would timeout waiting for the shutdown to complete and return too soon. The end result of this is that SBProcess::Kill() was broken on Windows. llvm-svn: 225297
* Only compile RegisterContextWindows_x86.cpp for x86 host architecture.Zachary Turner2014-12-184-4/+29
| | | | | | | | | | This fixes compilation failures in the 64-bit build of LLDB on Windows. Patch by Aidan Dodds Differential Revision: http://reviews.llvm.org/D6704 llvm-svn: 224528
* Fix some test failures for Windows.Zachary Turner2014-12-104-7/+53
| | | | llvm-svn: 223982
* Create a valid stop info for all non-breakpoint exceptions.Zachary Turner2014-12-091-2/+12
| | | | llvm-svn: 223812
* Subtract the size of the breakpoint opcode from the PC when getting the bp site.Zachary Turner2014-12-051-0/+4
| | | | llvm-svn: 223498
* Load / unload modules in the target when the OS events occur.Zachary Turner2014-12-052-3/+17
| | | | | | | This causes all deferred breakpoints to be correctly resolved as the modules that they reside in are loaded. llvm-svn: 223497
* Implement an empty DynamicLoader plugin for Windows.Zachary Turner2014-12-053-0/+144
| | | | llvm-svn: 223496
* Fix a minor error where I forgot to declare a variable.Zachary Turner2014-12-041-1/+2
| | | | llvm-svn: 223393
* Manually call ModulesDidLoad when the executable is loaded.Zachary Turner2014-12-031-0/+11
| | | | | | | | | This is a temporary workaround to get deferred breakpoint resolution working until Bug 21720 is addressed. Even with this workaround, it will only resolve deferred breakpoints in the executable module, and not in a shared library. llvm-svn: 223273
* Correctly shutdown when DoDestroy is called with an active exception.Zachary Turner2014-12-034-42/+109
| | | | | | | | | | | | | | | | | | | | | Previously if we got a DoDestroy while stopped at a breakpoint, we would detach and then say the process had exited. This is completely wrong, as it resulted in the python script incorrectly assuming that the process had actually exited and trying to delete the image, when in fact it had done no such thing. The fix employed here is that when we get a DoDestroy, we do 3 steps: 1) initiate a termination sequence on the process 2) If we were stopped handling an exception of any kind, mask it and let the program resume, causing the program to see the termination request and exit on its own. 3) Let the program exit normally, and close all of our handles before returning control back to DoDestroy. This fixes Bug 21722 and Bug 21723. llvm-svn: 223272
* Enable enabling and disabling breakpoints on Windows.Zachary Turner2014-12-012-0/+15
| | | | llvm-svn: 223089
* When a process stops, set the StopInfo object on Windows.Zachary Turner2014-11-253-0/+40
| | | | llvm-svn: 222776
* Disable GetSTDOUT, GetSTDERR, and PutSTDIN on Windows.Zachary Turner2014-11-252-40/+52
| | | | | | | | | | These methods are difficult / impossible to implement in a way that is semantically equivalent to the expectations set by LLDB for using them. In the future, we should find an alternative strategy (for example, i/o redirection) for achieving similar functionality, and hopefully deprecate these APIs someday. llvm-svn: 222775
* [ProcessWindows] Clean up the register definitions array.Zachary Turner2014-11-222-82/+122
| | | | llvm-svn: 222597
* Rename lldb registers to contain lldb_ prefix.Zachary Turner2014-11-211-22/+22
| | | | | | | | | | | | | | | | | | | | LLDB supports many different register numbering schemes, and these are typically prefixed with an indicator that lets the user know what numbering scheme is used. The gcc numbering scheme is prefixed with gcc, and there are similar ones for dwarf, gdb, and gcc_dwarf. LLDB also contains its own internal numbering scheme, but the enum for LLDB's numbering scheme was prefixed differently. This patch changes the names of these enums to use the same naming scheme for the enum values as the rest of the register kinds by removing gpr_ and fpu_ prefixes, and instead using lldb_ prefixes for all enum values. Differential Revision: http://reviews.llvm.org/D6351 Reviewed by: Greg Clayton llvm-svn: 222495
* [ProcessWindows] Implement a RegisterContextWindows for x86.Zachary Turner2014-11-206-11/+460
| | | | | | | | | | | | | | | This implements the skeleton of a RegisterContext for Windows. In particular, this implements support only for x86 general purpose registers. After this patch, LLDB on Windows can perform basic debugging operations in a single-threaded inferior process (breakpoint, register inspection, frame select, unwinding, etc). Differential Revision: http://reviews.llvm.org/D6322 Reviewed by: Greg Clayton llvm-svn: 222474
* Change HostThread::GetNativeThread() to return a derived reference.Zachary Turner2014-11-173-5/+5
| | | | | | | | Previously using HostThread::GetNativeThread() required an ugly cast to most-derived type. This solves the issue by simply returning the derived type directly. llvm-svn: 222185
* Move the thread logic around to fit better into LLDB's process model.Zachary Turner2014-11-173-27/+72
| | | | | | | | | | | Previously we were directly updating the thread list and stopping and restarting the process every time threads were created. With this patch, we queue up thread launches and thread exits, resolve these all internally, and only update the threads when we get an UpdateThreadList call. We now only update the private state on an actual stop (i.e. breakpoint). llvm-svn: 222178
* [ProcessWindows] Create a TargetThreadWindows class.Zachary Turner2014-11-175-48/+199
| | | | | | | | | | | This creates a TargetThreadWindows class and updates the thread list of the Process with the main thread. Additionally, we fill out a few more overrides of Process base class methods. We do not yet update the thread list as threads are created and/or destroyed, and we do not yet propagate stop reasons to threads as their states change. llvm-svn: 222148
* [ProcessWindows] Implement read / write process memory.Zachary Turner2014-11-172-3/+30
| | | | llvm-svn: 222147
* [ProcessWindows] Improve support for launching processes.Zachary Turner2014-11-126-63/+167
| | | | | | | | | | | | | This sends notifications for module load / unload to the process plugin, and also manages the state more accurately during the loading sequence. Similar work by Virgile Bello was referenced during the implementation of this patch. Differential Revision: http://reviews.llvm.org/D6224 llvm-svn: 221807
* [ProcessWindows] Simplify the DebugDelegate interface.Zachary Turner2014-11-128-209/+64
| | | | | | | | | | | Due to a previous multi-threaded design involving message passing, we used message classes to pass event information to the delegate. Since the multi-threaded design has gone away, we simplify this by passing event arguments as direct function parameters, which is more clear and easier to understand. llvm-svn: 221806
* [ProcessWindows] Implement breakpoint stop / resume on Windows.Zachary Turner2014-11-1110-11/+173
| | | | | | | | | | | | | | 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
* [ProcessWindows] Notify process plugin when the launch succeeds.Zachary Turner2014-11-109-53/+89
| | | | llvm-svn: 221637
* Remove the top-level DebugDriverThread in ProcessWindows.Zachary Turner2014-11-0714-860/+74
| | | | | | | | | | 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
* Decouple ProcessWindows from the Windows debug driver thread.Zachary Turner2014-11-0516-80/+381
| | | | | | | | | 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
* Rename some classes in ProcessWindows.Zachary Turner2014-11-0513-206/+308
| | | | | | | | | | | | 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
* Implement a framework for live debugging on Windows.Zachary Turner2014-11-0414-7/+1100
| | | | | | | | | | | | | | | | | 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
* Make ProcessWindows just use Host::LaunchProcess.Zachary Turner2014-10-241-5/+1
| | | | llvm-svn: 220574
* Create a process launcher abstraction.Zachary Turner2014-10-141-71/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Refactor FileAction out of ProcessLaunchInfo.Zachary Turner2014-08-141-1/+2
| | | | | | | | | | | | | 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
* Teach ProcessWindows plugin to support stdio i/o redirection.Zachary Turner2014-08-041-11/+61
| | | | llvm-svn: 214816
* Teach LLDB about Windows processes.Zachary Turner2014-07-283-0/+321
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
OpenPOWER on IntegriCloud