summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/Process.cpp
Commit message (Collapse)AuthorAgeFilesLines
* <rdar://problem/13635174>Greg Clayton2013-10-111-1/+11
| | | | | | | | Added a way to set hardware breakpoints from the "breakpoint set" command with the new "--hardware" option. Hardware breakpoints are not a request, they currently are a requirement. So when breakpoints are specified as hardware breakpoints, they might fail to be set when they are able to be resolved and should be used sparingly. This is currently hooked up for GDB remote debugging. Linux and FreeBSD should quickly enable this feature if possible, or return an error for any breakpoints that are hardware breakpoint sites in the "virtual Error Process::EnableBreakpointSite (BreakpointSite *bp_site);" function. llvm-svn: 192491
* Allow Process::WaitForProcessToStop to return immediately if process is ↵Daniel Malea2013-10-091-1/+14
| | | | | | | | | already in the stopped state - By default, the above function will wait for at least one event - Set wait_always=false to make the function return immediately if the process is already stopped llvm-svn: 192301
* Remove unnecessary checks for thread_plan_sp (we check for this at the top ↵Jim Ingham2013-09-271-2/+2
| | | | | | of the function.) llvm-svn: 191476
* Changing the default shell to /bin/sh brought up a long-standing bug on OS X,Jim Ingham2013-09-101-3/+4
| | | | | | | | | | | | | that /bin/sh re-exec's itself to /bin/bash, so it needs one more resume when you are using it as the shell than /bin/bash did or you will stop at the start of your program, rather than running it. So I added a Platform API to get the number of resumes needed when launching with a particular shell, and set the right values for Mac OS X. <rdar://problem/14935282> llvm-svn: 190381
* Add OptionParser.hVirgile Bello2013-09-051-12/+12
| | | | llvm-svn: 190063
* Switch '/bin/bash' to '/bin/sh'Ed Maste2013-09-031-1/+1
| | | | | | | | /bin/sh is more portable, and all systems with /bin/bash are expected to have /bin/sh as well, even if only a link to bash. Review: http://llvm-reviews.chandlerc.com/D1576 llvm-svn: 189879
* Fixed a few typos.Ashok Thirumurthi2013-08-271-1/+1
| | | | llvm-svn: 189355
* Fix some names in the wake of my Mach-O changes to LLVM.Charles Davis2013-08-271-1/+7
| | | | llvm-svn: 189317
* MingW compilation (windows). Includes various refactoring to improve ↵Virgile Bello2013-08-231-3/+5
| | | | | | portability. llvm-svn: 189107
* Fix lock hierarchy violation in Process (lock ordering of ThreadList mutex ↵Daniel Malea2013-07-311-0/+1
| | | | | | | | | | | | | | and StackFrameList mutex) - this fix ensures the ThreadList mutex is always locked before the StackFrameList mutex Situation where deadlock could occur (without this fix): Thread 1 is in Process::WillResume and locks the ThreadList mutex (on entry), and subsequently calls StackFrameList::Clear() which locks the StackFrameList mutex. Meanwhile, thread 2 is in Process::RunThreadPlan and calls Thread::SetSelectedFrame() (which locks the StackFrameList mutex) before calling GetSelectedThread (which attempts to lock the ThreadList mutex) In my testing on both Linux and Mac OS X, I was unable to reproduce any hangs with this patch applied. llvm-svn: 187522
* Send a stop event when an expression stops at a breakpointSean Callanan2013-07-301-0/+6
| | | | | | | | | | in an expression and doesn't ignore the stop. Patch by Jim Ingham. <rdar://problem/14583884> llvm-svn: 187434
* Use flag instead of rwlock state to track process running stateEd Maste2013-07-291-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLDB requires that the inferior process be stopped before, and remain stopped during, certain accesses to process state. Previously this was achieved with a POSIX rwlock which had a write lock taken for the duration that the process was running, and released when the process was stopped. Any access to process state was performed with a read lock held. However, POSIX requires that pthread_rwlock_unlock() be called from the same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start the process from different threads. Violating this constraint is technically undefined behaviour, although as it happens Linux and Darwin result in the unlock proceeding in this case. FreeBSD follows POSIX more strictly, and the unlock would fail, resulting in a hang later upon the next attempt to take the lock. All read lock consumers use ReadTryLock() and handle failure to obtain the lock (typically by logging an error "process is running"). Thus, instead of using the lock state itself to track the running state, this change adds an explicit m_running flag. ReadTryLock tests the flag, and if the process is not running it returns with the read lock held. WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning, and (if successful) they set m_running with the lock held. This way, read consumers can determine if the process is running and act appropriately, and write consumers are still held off from starting the process if read consumers are active. Note that with this change there are still some curious access patterns, such as calling WriteUnlock / SetStopped twice in a row, and there's no protection from multiple threads trying to simultaneously start the process. In practice this does not seem to be a problem, and was exposing other undefined POSIX behaviour prior to this change. llvm-svn: 187377
* Remove obsolete commentEd Maste2013-07-021-4/+1
| | | | llvm-svn: 185441
* Remove the process's reservation cache and don'tSean Callanan2013-06-271-58/+0
| | | | | | | | | | | | | | | | | | | | | | bother checking if a region is safe to use. In cases where regions need to be synthesized rather than properly allocated, the memory reads required to determine whether the area is used are - insufficient, because intermediate locations could be in use, and - unsafe, because on some platforms reading from memory can trigger events. All this only makes a difference on platforms where memory allocation in the target is impossible. Behavior on platforms where it is possible should stay the same. <rdar://problem/14023970> llvm-svn: 185046
* <rdar://problem/14182286>Han Ming Ong2013-06-241-7/+8
| | | | | | | | Made sure that temporary object created from HarmonizeThreadIdsForProfileData() doesn’t get passed around without creating an object first. Reviewed by Greg llvm-svn: 184769
* Remember to update the m_thread_list_real after you do UpdateThreadList.Jim Ingham2013-06-221-0/+2
| | | | | | <rdar://problem/14147303> llvm-svn: 184622
* <rdar://problem/14004410>Han Ming Ong2013-06-211-9/+0
| | | | | | Remove old GetNextThreadIndexID() from lldb llvm-svn: 184600
* Sort out a number of mismatched integer types in order to cut down the ↵Andy Gibbs2013-06-191-1/+1
| | | | | | number of compiler warnings. llvm-svn: 184333
* Don't actually Halt in the Interrupt handler for the Process, just send an ↵Jim Ingham2013-06-191-1/+1
| | | | | | | | AsyncInterrupt. That's actually not async-signal-clean, but it is a lot safer than Halt... llvm-svn: 184270
* Huge performance improvements when one breakpoint contains many locations.Greg Clayton2013-06-121-70/+74
| | | | | | | | | | 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
* Adding support for stopping all threads of multithreaded inferiors on Linux. ↵Andrew Kaylor2013-05-281-1/+1
| | | | | | Also adding multithreaded test cases. llvm-svn: 182809
* Added a test case that verifies that LLDB can debug across a process ↵Greg Clayton2013-05-211-2/+0
| | | | | | | | exec'ing itself into a new program. This currently is only enabled for Darwin since we exec from 64 bit to 32 bit and vice versa for 'x86_64' targets. This can easily be adapted for linux and other platforms, but I didn't want to break any buildbots by assuming it will work. llvm-svn: 182428
* <rdar://problem/13892516>Greg Clayton2013-05-211-1/+5
| | | | | | LLDB can now debug across calls to exec when the architecture changes from say i386 to x86_64 (on darwin). llvm-svn: 182345
* Added a per-process cache for reserved memorySean Callanan2013-05-161-0/+58
| | | | | | | | | | | | | | | | regions that aren't actually allocated in the process. This cache is used by the expression parser if the underlying process doesn't support memory allocation, to avoid needless repeated searches for unused address ranges. Also fixed a silly bug in IRMemoryMap where it would continue searching even after it found a valid region. <rdar://problem/13866629> llvm-svn: 182028
* Don’t pop the process input reader for a “stop” event if ↵Jim Ingham2013-05-151-1/+1
| | | | | | ShouldBroadcastEvent has restarted the process. llvm-svn: 181859
* <rdar://problem/13700260>Greg Clayton2013-05-101-1/+13
| | | | | | Avoid a deadlock when using the OperatingSystemPython code and typing "process interrupt". There was a possible lock inversion between the target API lock and the process' thread list lock due to code trying to discard the thread list. This was fixed by adding a boolean to Process::Halt() that indicates if the thread plans should be discarded and doing it in the private state thread when we process the stopped state. llvm-svn: 181651
* <rdar://problem/13854277>Greg Clayton2013-05-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <rdar://problem/13594769> Main changes in this patch include: - cleanup plug-in interface and use ConstStrings for plug-in names - Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp - Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging The plug-in interface changes: Modified the lldb_private::PluginInterface class that all plug-ins inherit from: Changed: virtual const char * GetPluginName() = 0; To: virtual ConstString GetPluginName() = 0; Removed: virtual const char * GetShortPluginName() = 0; - Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names. - Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc. llvm-svn: 181631
* Adding support for setting thread stop state when a process stops.Andrew Kaylor2013-05-101-0/+14
| | | | | | This re-submission of this patch fixes a problem where the code sometimes caused a deadlock. The Process::SetPrivateState method was locking the Process::m_private_state variable and then later calling ThreadList::DidStop, which locks the ThreadList mutex. Other methods in ThreadList which were being called from other threads lock the ThreadList mutex and then call Process::GetPrivateState which locks the Process::m_private_state mutex. To avoid deadlocks, Process::SetPrivateState now locks the ThreadList mutex before locking the Process::m_private_state mutex. llvm-svn: 181609
* Revert r181482 as it causes occasional hangs in LLDB buildbotsDaniel Malea2013-05-091-13/+0
| | | | llvm-svn: 181526
* Adding code to set thread state to stopped when the process stops.Andrew Kaylor2013-05-081-0/+13
| | | | llvm-svn: 181482
* Remove distinction between Apple/Linux for Process run locks:Daniel Malea2013-05-081-13/+0
| | | | | | | | - Played with the current dual run lock implementation for a few days, noticed no regressions, so enabling in trunk so we see if any problems are detected by buildbots. llvm-svn: 181446
* Figure out the reply to "PlanExplainsStop" once when we stop and then use ↵Jim Ingham2013-05-081-16/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
* Reinstating r181091 and r181106 with fix for Linux regressions.Andrew Kaylor2013-05-071-6/+18
| | | | llvm-svn: 181340
* Temporarily reverting r181091 and r181106 due to the vast test breakage on ↵Ashok Thirumurthi2013-05-071-18/+6
| | | | | | | | | | the Linux buildbots while we develop a better understanding of how to manage the thread lists in a platform-independant fashion. Reviewed by: Daniel Malea llvm-svn: 181323
* After recent OperatingsSystem plug-in changes, the lldb_private::Process and ↵Greg Clayton2013-05-041-6/+18
| | | | | | | | | | lldb_private::Thread subclasses were changed and the API was not respected properly. This checkin aims to fix this. The process now has two thread lists: a real thread list for threads that are created by the lldb_private::Process subclass, and the user visible threads. The user visible threads are the same as the real threas when no OS plug-in in used. But when an OS plug-in is used, the user thread can be a combination of real and "memory" threads. Real threads can be placed inside of memory threads so that a thread appears to be different, but is still controlled by the actual real thread. When the thread list needs updating, the lldb_private::Process class will call the: lldb_private::Process::UpdateThreadList() function with the old real thread list, and the function is expected to fill in the new real thread list with the current state of the process. After this function, the process will check if there is an OS plug-in being used, and if so, it will give the old user thread list, the new real thread list and the OS plug-in will create the new user thread list from both of these lists. If there is no OS plug-in, the real thread list is the user thread list. These changes keep the lldb_private::Process subclasses clean and no changes are required. llvm-svn: 181091
* Don't check the private state in DoOnRemoval, check whether THIS event ↵Jim Ingham2013-05-031-1/+1
| | | | | | | | caused a restart. rdar://problem/13788593 llvm-svn: 181068
* Clear up any deadlocks on Apple builds that were due to the ↵Greg Clayton2013-05-031-23/+14
| | | | | | | | lldb_private::Process.m_private_run_lock variable. If someone on Linux and/or FreeBSD can try to comment out the " #if defined(__APPLE__)" that surrounds access to "m_private_run_lock" and run the test suite, that would be nice. The new location where the locking/unlocking happens is bulletproof on MacOSX, and I want to verify that it is good on linux as well. llvm-svn: 181061
* Recommitting r180831 with trivial fix - remember to return errors if you ↵Jim Ingham2013-05-021-4/+28
| | | | | | compute. llvm-svn: 180898
* Return zero when we don't support the byte size. Previously is we were asked ↵Greg Clayton2013-05-011-20/+14
| | | | | | to read 3, 5, 6, or 7 byte integers, we would set the error, but still return that we read that number of bytes without populating the scalar. llvm-svn: 180896
* Fixed Process::ReadScalarIntegerFromMemory()Sean Callanan2013-05-011-3/+15
| | | | | | | | | to report proper errors when the size is not correct. <rdar://problem/13784456> llvm-svn: 180888
* Reverting 180831 as it crashes TestDefaultConstructorForAPIObjects.pyDaniel Malea2013-05-011-28/+4
| | | | llvm-svn: 180868
* Added an option to "process detach" to keep the process stopped, if the ↵Jim Ingham2013-04-301-4/+28
| | | | | | | | | | process plugin (or in the case of ProcessGDBRemote the stub we are talking to) know how to do that. rdar://problem/13680832 llvm-svn: 180831
* In Process::ProcessEventData::DoOnRemoval, we need to handle the case where ↵Jim Ingham2013-04-251-1/+8
| | | | | | | | | | | NO thread has a stop reason specially, and make sure we stop. This shouldn't happen, but if it does, the user will probably want to see it. <rdar://problem/13273125> llvm-svn: 180244
* Fixed some linux buildbot warnings.Greg Clayton2013-04-191-1/+1
| | | | llvm-svn: 179892
* Provided a variant of ReadCStringFromMemory that supports null terminators ↵Ashok Thirumurthi2013-04-191-0/+54
| | | | | | | | | | | | | | | | | | of any character width. This prevents unbounded reads (i.e. reads of GetMaximumSizeOfStringSummary() bytes) from causing test failures (i.e. due to ptrace EIO or EFAULT on Linux). Note that ReadCStringFromMemory is marked as deprecated because the loop that calls ReadMemory does not continue until the string has been completely read. The expected behavior is to read until until max_bytes or a null terminator. Note: As discussed on lldb-dev, further testing will be performed with ReadStringFromMemory before further changes are made for users of ReadCStringFromMemory. Thanks to Enrico, Matt and Andy for their review feedback. llvm-svn: 179857
* After discussing with Chris Lattner, we require C++11, so lets get rid of ↵Greg Clayton2013-04-181-1/+1
| | | | | | the macros and just use C++11. llvm-svn: 179805
* Since we use C++11, we should switch over to using std::unique_ptr when ↵Greg Clayton2013-04-181-1/+1
| | | | | | | | C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++. Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro. llvm-svn: 179779
* Re-enable m_private_run_lock changes from 179329, but only for Apple hosted ↵Greg Clayton2013-04-181-9/+29
| | | | | | builds so it doesn't break the buildbots. We will try and work the issues out in the Apple build before enabling this feature for everyone. llvm-svn: 179772
* Revert of r179378 and r179329, which introduce a private thread lock around ↵Ashok Thirumurthi2013-04-181-27/+11
| | | | | | | | thread enumeration, in order to prevent consistent hangs on all 3 LLDB buildbots. llvm-svn: 179759
* Fixed a few m_private_run_lock issues when attaching and also fixed the ↵Greg Clayton2013-04-181-2/+7
| | | | | | process to not try to restart the process if the process is exited, crashed or detached. Partial patch from Carlo Kok. llvm-svn: 179738
OpenPOWER on IntegriCloud