summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process
Commit message (Collapse)AuthorAgeFilesLines
...
* Added support for writing registers larger than 64 bitsChaoren Lin2015-02-031-5/+9
| | | | llvm-svn: 227919
* LLGS local - signal stops inferior in debuggerChaoren Lin2015-02-031-20/+1
| | | | | | | | | | | | | NativeProcessLinux::MonitorSignal was automatically resuming threads that stopped due to a signal.  This is inconsistent with the behavior of lldb and gdb.  This change removes the automatic resume. Fixes TestSendSignal.py TestSignalsAPI.py if PLATFORM_LINUX_FORCE_LLGS_LOCAL is in the environment vars. llvm-svn: 227918
* Fix up NativeProcessLinux::Interrupt() to use thread state coordinator ↵Chaoren Lin2015-02-032-0/+76
| | | | | | mechanism. llvm-svn: 227917
* Added code to prevent "administrative stop" from overwriting a real stop reason.Chaoren Lin2015-02-031-5/+38
| | | | | | | | | | | | Note this code path should not happen - it implies a bug in another part of the code. For the thread to receive the stop signal as it is handled, the and for it to already have a stop reason, it implies the kernel was able to tell the thread that it stopped while it was stopped. More likely this seems to indicate a bug where an actual thread start was not getting correctly logged. If it does get hit, we'll want to understand the sequence to figure out if it is truly legitimate or if it implies another bug. llvm-svn: 227916
* Fix step commands that mix running threads and stepping threads.Chaoren Lin2015-02-031-5/+0
| | | | | | This fixes https://github.com/tfiala/lldb/issues/62. llvm-svn: 227915
* Disabled local-llgs hijacking of state on startup; passed along signo to ↵Chaoren Lin2015-02-031-13/+2
| | | | | | | | | | | killed process. It looks like Shawn's fix addresses what the initial hijacking was trying to accomplish per conversations with Greg and Jim. The hijacking was causing several tests to hang (#61, #62, #63, #64, #67, possibly more). These tests now just fail rather than hang with this modification. llvm-svn: 227914
* Fix some bugs in llgs thread state handling.Chaoren Lin2015-02-034-24/+64
| | | | | | | | | | | | | | | | | | | | | | * When the thread state coordinator is told to skip sending a stop request for a running thread that is ignored (e.g. the thread that steps in a step operation is technically running and should not have a stop sent to it, since it will stop of its own accord per the kernel step operation), ensure the deferred signal notification logic still waits for the skipped thread. (i.e. we want to defer the notification until the stepping thread is indeed stopped, we just don't want to send it a tgkill). * Add ThreadStateCoordinator::RequestResumeAsNeeded(). This variant of the RequestResume() method does not call the error function when the thread is already running. Instead, it just logs that the thread is already running and skips the resume operation. This is useful for the case of vCont;c handling, where we tell all threads that they should be running. At the place we're calling, all we know is "we want this thread running if it isn't already," and that's exactly what this command does. * Formatting change (minor) in NativeThreadLinux logging. llvm-svn: 227913
* llgs: more work on thread stepping.Chaoren Lin2015-02-034-9/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | See https://github.com/tfiala/lldb/issues/75. Not fixed yet but continuing to push this further. Fixes: * Resume() now skips doing deferred notifications if we're doing a vCont;{c,C}. In this case, we're trying to start something up, not defer a stop notification. The default thread action stop mode pickup was triggering a stop because it had at least one stop, which was wrong in the case of a continue. (Bug introduced by previous change.) * Added a variant to ThreadStateCoordinator to specify a set of thread ids to be skipped when triggering stop notifications to non-stopped threads on a deferred signal call. For the case of a stepping thread, it is actually told to step (and is running) for a brief moment, but the thread state coordinator would think it needed to send the stepping thread a stop, which id doesn't need to do. This facility allows me to get around that cleanly. With this change, behavior is now reduced to something I think is essentially a different bug: * Doing a step into libc code from my code crashes llgs. * Doing a next out of a function in my own code crashes llgs. llvm-svn: 227912
* llgs: fix up some handling of stepping.Chaoren Lin2015-02-032-41/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Tracked down while working on https://github.com/tfiala/lldb/issues/75. This is not a complete fix for that issue, but moves us farther along. Fixes: * When a thread step is requested via vCont:{s,S}, Resume() now marks the stepping thread as (1) currently stepping and (2) does trigger the deferred signal for the stepped thread. This fixes a bug where we were actually triggering a deferred stop cycle here for the non-stepping thread since the single step thread was not part of the Resume() deferred signal mechanism. The stepping thread is also marked in the thread state coordinator as running (via a resume callback). * When we get the SIGTRAP signal for the step completion, we don't do a deferred signal call - that happened during the vCont:{s,S} processing in Resume() already. Now we just need to mark that the stepping thread is now stopped. If this is the last thread in the set that needs to stop, it will trigger the process/delegate stop call that will notify lldb. Otherwise, that'll happen when the final thead we're waiting for stops. Misc: * Fixed up thread stop logging to use a leading 0 (0x%PRIx32) so we don't get log lines like 0x5 for 0x05 SIGTRAP. llvm-svn: 227911
* llgs: fixed a bug in deferred signal thread id; added coordinator enqueue ↵Chaoren Lin2015-02-032-1/+5
| | | | | | | | | logging. The deferred signal thread id was being set with the process id unintentionally in NativeProcessLinux::CallAfterRunningThreadsStop(). llvm-svn: 227910
* Get initial thread state coordinator integration working.Chaoren Lin2015-02-034-421/+556
| | | | | | | | | | | | | | | | | | | | * Fixed bug in run loop where run loop return enum was being treated erroneously like an int, causing the TSC event loop to terminate prematurely. * Added an explicit scope in NativeProcessLinux::Resume() for the threads lock lifetime. (This was likely unnecessary but is more explicit.) * Fixed a bug in ThreadStateCoordinator where resume execution was not updating the internal state about the thread assumed to be running now. I'll add a test and upstream this in a moment. * Added a verbose logging mechanism to event processing within ThreadStateCoordinator. It is currently enabled when the 'log enable lldb thread' is true upon inferior launch/attach. llvm-svn: 227909
* Launch lldb-gdbserver in same process group when launched remotely using ↵Oleksiy Vyalov2015-01-283-4/+13
| | | | | | | | lldb-platform - commit on behalf of flackr. http://reviews.llvm.org/D7211 llvm-svn: 227329
* Fixing TestRegisters on Linux with LLGSVince Harron2015-01-237-8/+55
| | | | | | | | | | | | | | This patch fixes TestRegisters on Linux with LLGS Introduce GetUserRegisterCount on RegisterInfoInterface to distinguish lldb internal registers (e.g.: DR0-DR7) during register counting. Update GDBRemoteCommunicationServer to skip lldb internal registers on read/write register and on discover register. Submitted for Tamas Berghammer llvm-svn: 226959
* Implement ProcessWindows::GetMemoryRegionInfo.Zachary Turner2015-01-212-0/+39
| | | | llvm-svn: 226742
* This patch gets remote-linux platform able to run processesVince Harron2015-01-214-4/+21
| | | | | | | | | | | | | | | | Make sure the selected platform is always used Make sure that the host uses the connect://hostname to connect to both the lldb-platform and the lldb-gdbserver rather than what the platform reports as the hostname of the lldb-gdbserver Make sure that lldb-platform uses the IP address on it's connection back to the host instead of the hostname that the host sends to it when launching lldb-gdbserver with the remote host information Tested on OSX and Linux llvm-svn: 226712
* Adding compact unwind as a source of unwind information Jason Molenda2015-01-211-2/+5
| | | | | | | | | | | | | | introduced subtle bugs in two places in RegisterContextLLDB::GetFullUnwindPlanForFrame where it specifically wanted to get an eh_frame unwind plan and was using "Get CallSite UnwindPlan" as synonymous with that. But now we have two different types of unwind plan that can be returned in that case, and compact unwind won't behaves as needed. <rdar://problem/19528559> llvm-svn: 226631
* Add Socket::Get[Remote/Local]IpAddress and unit testsVince Harron2015-01-161-1/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D6917 llvm-svn: 226234
* 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
* Moved Args::StringToXIntYZ to StringConvert::ToXIntYZVince Harron2015-01-155-47/+51
| | | | | | | | | | The refactor was motivated by some comments that Greg made http://reviews.llvm.org/D6918 and also to break a dependency cascade that caused functions linking in string->int conversion functions to pull in most of lldb llvm-svn: 226199
* 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
* Extend PipePosix with support for named pipes/timeout-based IO and integrate ↵Oleksiy Vyalov2015-01-141-3/+2
| | | | | | | | it with GDBRemoteCommunication / lldb-gdbserver - include reviews fixes. http://reviews.llvm.org/D6954 llvm-svn: 225923
* Extend PipePosix with support for named pipes/timeout-based IO and integrate ↵Oleksiy Vyalov2015-01-131-18/+36
| | | | | | | | it with GDBRemoteCommunication / lldb-gdbserver. http://reviews.llvm.org/D6954 llvm-svn: 225849
* Fixed an issue where if the operating system python plug-in is changed at ↵Greg Clayton2015-01-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
* Hoist the RegisterNumber class out of RegisterContextLLDB and makeJason Molenda2015-01-101-159/+1
| | | | | | | | | | | | | | | it more generally available. Add checks to UnwindAssembly_x86::AugmentUnwindPlanFromCallSite() so that it won't try to augment an UnwindPlan that already describes the function epilogue. Add a test case for backtracing out of _sigtramp on Darwin systems. This could probably be adapted to test the same thing on linux/bsd but the function names of sigtramp and kill are probably platform specific and I'm not sure what they should be. llvm-svn: 225578
* Rearrange RegisterContextLLDB::SavedLocationForRegister a tiny bitJason Molenda2015-01-081-18/+22
| | | | | | | | | | | | | so that we will use the UnwindPlan's rule for providing the stack pointer BEFORE we use the trick of using the callee's CFA address as the stack pointer. When we're in a _sigtramp frame, the CFA of the _sigtramp stack frame is not the same as the stack pointer value when the async interrupt occurred -- we need to use the eh_frame rules for retrieving the correct value. <rdar://problem/18913548> llvm-svn: 225427
* Put FreeBSD note types in their own namespaceEd Maste2015-01-061-10/+14
| | | | | | | Note types are inherently OS-specific, but some note type names are common to both FreeBSD and Linux. llvm-svn: 225299
* 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
* Make sure if a thread specifies a 'register_data_addr' in a python operating ↵Greg Clayton2014-12-111-1/+1
| | | | | | system plug-in, that is is used to fetch the register values. llvm-svn: 224083
* Make sure we print errors for python OperatingSystem plug-ins for when ↵Greg Clayton2014-12-111-0/+12
| | | | | | things go wrong. We also dump the dictionary or collection that had errors so the user can see which info was wrong. llvm-svn: 224082
* Fix some test failures for Windows.Zachary Turner2014-12-104-7/+53
| | | | llvm-svn: 223982
* Add D request handler to GDBRemoteCommunicationServer in order to support ↵Oleksiy Vyalov2014-12-102-1/+73
| | | | | | detach from inferior. llvm-svn: 223901
* Handle thumb IT instructions correctly all the time.Greg Clayton2014-12-092-4/+38
| | | | | | | | | | | | | | | | | | | | | | The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true. When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction. The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match. To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed. This patch does the following: 1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb 2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute 3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb 4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below) This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added. <rdar://problem/19145455> llvm-svn: 223851
* Add a new 'eRegisterInLiveRegisterContext' RegisterLocation to trackJason Molenda2014-12-093-9/+44
| | | | | | | | | | | | | | a register value that is live in the stack frame 0 register context. Fixes a problem where retrieving a register value on stack frame #n would involved O(n!) stack frame checks. This could be very slow on a deep stack when retrieving register values that had not been modified/saved by any of the stack frames. Not common, but annoying when it was hit. <rdar://problem/19010211> llvm-svn: 223843
* Create a valid stop info for all non-breakpoint exceptions.Zachary Turner2014-12-091-2/+12
| | | | llvm-svn: 223812
* Add Linux support for HostInfo::GetOSBuildString and ↵Oleksiy Vyalov2014-12-091-2/+0
| | | | | | HostInfo::GetOSKernelDescription. llvm-svn: 223737
* The lldb unwinder can now use the unwind information from the compact-unwind Jason Molenda2014-12-081-4/+7
| | | | | | | | | | | | | | | | | | section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
* 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
* Revert "Use timeout when reading debugserver's port from a named pipe."Zachary Turner2014-12-041-55/+12
| | | | | | | | | | This reverts commit 4a5ad2c077166cc3d6e7ab4cc6e3dcbbe922af86. Windows doesn't support select() for pipe objects, and this also fails to compile on Windows. Reverting this until we can get it sorted out to keep the windows build working. llvm-svn: 223392
* 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
* Use timeout when reading debugserver's port from a named pipe.Oleksiy Vyalov2014-12-031-12/+55
| | | | | | http://reviews.llvm.org/D6490 llvm-svn: 223251
* 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
* When a RegisterContext produces an invalid CFA address, changeJason Molenda2014-11-222-15/+42
| | | | | | | | | | | | | | | | | UnwindLLDB::AddOneMoreFrame to try the fallback unwind plan on that same stack frame before it tries the fallback unwind plan on the "next" or callee frame. In RegisterContextLLDB::TryFallbackUnwindPlan, when we're trying the fallback unwind plan to see if it is valid, make sure we change all of the object ivars that might be used in the process of fetching the CFA & caller's saved pc value and restore those if we decide not to use the fallback unwindplan. <rdar://problem/19035079> llvm-svn: 222601
OpenPOWER on IntegriCloud