summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/Thread.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Adding support for setting thread stop state when a process stops.Andrew Kaylor2013-05-101-0/+6
| | | | | | 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-6/+0
| | | | llvm-svn: 181526
* Changed the formerly pure virtual function:Greg Clayton2013-05-091-28/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | namespace lldb_private { class Thread { virtual lldb::StopInfoSP GetPrivateStopReason() = 0; }; } To not be virtual. The lldb_private::Thread now handles the correct caching and will call a new pure virtual function: namespace lldb_private { class Thread { virtual bool CalculateStopInfo() = 0; } } This function must be overridden by thead lldb_private::Thread subclass and the only thing it needs to do is to set the Thread::StopInfo() with the current stop reason and return true, or return false if there is no stop reason. The lldb_private::Thread class will take care of calling this function only when it is required. This allows lldb_private::Thread subclasses to be a bit simpler and not all need to duplicate the cache and invalidation settings. Also renamed: lldb::StopInfoSP lldb_private::Thread::GetPrivateStopReason(); To: lldb::StopInfoSP lldb_private::Thread::GetPrivateStopInfo(); Also cleaned up a case where the ThreadPlanStepOverBreakpoint might not re-set its breakpoint if the thread disappears (which was happening due to a bug when using the OperatingSystem plug-ins with memory threads and real threads). llvm-svn: 181501
* Adding code to set thread state to stopped when the process stops.Andrew Kaylor2013-05-081-0/+6
| | | | llvm-svn: 181482
* Figure out the reply to "PlanExplainsStop" once when we stop and then use ↵Jim Ingham2013-05-081-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+12
| | | | llvm-svn: 181340
* Temporarily reverting r181091 and r181106 due to the vast test breakage on ↵Ashok Thirumurthi2013-05-071-12/+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/+12
| | | | | | | | | | 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
* <rdar://problem/13700260>Greg Clayton2013-05-011-16/+38
| | | | | | | | | | | | | | <rdar://problem/13723772> Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves. A few things are introduced: - lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread. - Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification. - Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them - Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation. llvm-svn: 180886
* <rdar://problem/13697881>Greg Clayton2013-04-201-14/+19
| | | | | | Fixed the GDB remote with the python OS plug-in to not show core threads when they aren't desired and also to have the threads "to the right thing" when continuing. llvm-svn: 179912
* <rdar://problem/13516463>Greg Clayton2013-04-021-45/+66
| | | | | | Don't crash when there is no register context for a thread with kernel debugging. The kernel debugging uses the OperatingSystemPlugin that may behave badly when trying to get thread state, so be prepared to have invalid register contexts in threads. llvm-svn: 178574
* <rdar://problem/13521159>Greg Clayton2013-03-271-9/+9
| | | | | | | | LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
* Remove some commented out code.Jim Ingham2013-03-211-8/+0
| | | | llvm-svn: 177668
* Don't use the fact that we stopped with a "Breakpoint" stop reason to decide ↵Jim Ingham2013-03-131-5/+7
| | | | | | | | to step over the breakpoint. It's better to check directly whether there is a breakpoint site at the PC. llvm-svn: 176919
* Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction ↵Jim Ingham2013-02-091-4/+19
| | | | | | | | | | | interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
* Make sure a value is returned for Thread::ReturnFromFrame().Greg Clayton2013-02-011-2/+1
| | | | llvm-svn: 174141
* Add "thread return -x" to unwind the innermost user called expression (if ↵Jim Ingham2013-01-311-11/+74
| | | | | | | | | | you happen to have stopped in it due to a crash.) Make the message when you hit an crash while evaluating an expression a little clearer, and mention "thread return -x". rdar://problem/13110464 llvm-svn: 174095
* Separated the "expr --unwind-on-error" behavior into two parts, actual ↵Jim Ingham2013-01-151-3/+10
| | | | | | | | | | | | | | | | errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
* <rdar://problem/12976225>Han Ming Ong2013-01-081-2/+1
| | | | | | Checking in the support for doing index ids reservation when given a thread id. llvm-svn: 171904
* Adding eStopReasonThreadExiting and fixing the handling of this state on Linux.Andrew Kaylor2012-12-201-9/+10
| | | | llvm-svn: 170800
* Fixed a few bugs in the "step in" thread plan logic.Jim Ingham2012-12-121-13/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | Added a "step-in-target" flag to "thread step-in" so if you have something like: Process 28464 stopped * thread #1: tid = 0x1c03, function: main , stop reason = breakpoint 1.1 frame #0: 0x0000000100000e08 a.out`main at main.c:62 61 -> 62 int A6 = complex (a(4), b(5), c(6)); // Stop here to step targetting b and hitting breakpoint. 63 and you want to get into "complex" skipping a, b and c, you can do: (lldb) step -t complex Process 28464 stopped * thread #1: tid = 0x1c03, function: complex , stop reason = step in frame #0: 0x0000000100000d0d a.out`complex at main.c:44 41 42 int complex (int first, int second, int third) 43 { -> 44 return first + second + third; // Step in targetting complex should stop here 45 } 46 47 int main (int argc, char const *argv[]) llvm-svn: 170008
* Fix Linux build warnings due to redefinition of macros:Daniel Malea2012-12-051-0/+2
| | | | | | | | | - add new header lldb-python.h to be included before other system headers - short term fix (eventually python dependencies must be cleaned up) Patch by Matt Kopec! llvm-svn: 169341
* <rdar://problem/12649160>Greg Clayton2012-12-051-0/+1
| | | | | | Added the ability to debug through your process exec'ing itself to the same architecture. llvm-svn: 169340
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-21/+21
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* The Function calling thread plan was replacing the stored stop info too ↵Jim Ingham2012-11-261-1/+7
| | | | | | | | | | soon, causing recursive entry into the breakpoint StopInfo's PerformAction, which is bad. Reworked this so that it is now correct. <rdar://problem/12501259> llvm-svn: 168634
* Rest of the fix for ThreadFilipe Cabecinhas2012-11-201-1/+1
| | | | llvm-svn: 168343
* Patch from Andrew Kaylor andrew.kaylor@intel.com to haveJason Molenda2012-11-141-0/+2
| | | | | | | Thread::ResetFrameZeroRegisters() clear the UnwindLLDB object when resetting the thread's register state. llvm-svn: 167910
* <rdar://problem/12500785>Greg Clayton2012-10-291-1/+6
| | | | | | | | I tracked down a leak that could happen when detaching from a process where the lldb_private::Process objects would stay around forever. This was caused by a eStateDetached event that was queued up on the lldb_private::Process private state thread listener. Since process events contain shared pointers to the process, this is dangerous if they don't get consume or cleared as having the lldb_private::Process class contain a collection of things that have a shared pointer to yourself is obviously bad. To fix this I modified the Process::Finalize() function to clear this list. The actual thing that was holding onto the ModuleSP and thus the static archive, was a stack frame. Since the process wasn't going away, it still had thread objects and they still had frames. I modified the Thread::Destroy() to clear the stack frames to ensure this further doesn't happen. llvm-svn: 166964
* Patch from Matt Kopec <matt.kopec@intel.com> to fix the problem that if two ↵Jim Ingham2012-10-161-4/+25
| | | | | | | | breakpoints were set on consecutive addresses, the continue from the first breakpoint would skip the second. llvm-svn: 166000
* Bunch of cleanups for warnings found by the llvm static analyzer.Jim Ingham2012-10-121-0/+1
| | | | llvm-svn: 165808
* Change the Thread constructor over to take a Process& rather than a ↵Jim Ingham2012-10-101-6/+140
| | | | | | | | | | | | | ProcessSP. We can't create Threads with a NULL ProcessSP, so it makes no sense to use the SP. Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame changes the stack. Made the Driver use this notification to print the new thread status rather than doing it in the command. Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call. <rdar://problem/12383087> llvm-svn: 165640
* Fix a bug introduced in an earlier revision: actually return the StopReason, ↵Filipe Cabecinhas2012-09-281-1/+1
| | | | | | when we have a StopInfo object. llvm-svn: 164825
* Implement returning integer values in "thread return" for arm, x86_64 and ↵Jim Ingham2012-09-271-3/+27
| | | | | | | | | | i386. Also returns floats & doubles on x86_64. <rdar://problem/8356523> llvm-svn: 164741
* <rdar://problem/9959501>Greg Clayton2012-09-251-1/+12
| | | | | | More KDP debugging process. We can not set breakpoints, hit them, resume, step and detach while running. llvm-svn: 164584
* Make the unwinding of the stack part of "thread return" work, and add the ↵Jim Ingham2012-09-141-8/+13
| | | | | | thread return command. llvm-svn: 163867
* Start at getting "thread return" working. Doesn't work yet.Jim Ingham2012-09-121-1/+63
| | | | llvm-svn: 163670
* Initialize a variable to quite a compiler warning.Jim Ingham2012-09-111-1/+1
| | | | llvm-svn: 163576
* Save and restore the current inlined depth over function calls.Jim Ingham2012-09-071-0/+3
| | | | llvm-svn: 163433
* Move calculating the CurrentInlinedDepth to AFTER the synchronous breakpoint ↵Jim Ingham2012-09-051-3/+7
| | | | | | | | callback gets a chance to run. If the stopped event comes in with the Restarted bit set, don't try to hand that to the plans, but just return ShouldStop = false. There's nothing useful the plans can do, since the target is already running. llvm-svn: 163244
* Initial check-in of "fancy" inlined stepping. Doesn't do anything useful ↵Jim Ingham2012-09-011-4/+14
| | | | | | | | | unless you switch LLDB_FANCY_INLINED_STEPPING to true. With that on, basic inlined stepping works, including step-over of inlined functions. But for some as yet mysterious reason i386 debugging gets an assert and dies immediately. So for now its off. llvm-svn: 163044
* Rework how the API mutex is acquired when filling out an ExecutionContext ↵Jim Ingham2012-08-221-1/+1
| | | | | | | | | | | | | | | | | from an ExecutionContextRef, particularly in the SBThread & SBFrame interfaces. Instead of filling the whole context & then getting the API mutex, we now get only the target, acquire the API mutex from it, then fill out the rest of the context. This removes a race condition where you get a ThreadSP, then wait on the API mutex while another command Destroy's the Thread you've just gotten. Also fixed the ExecutionContextRef::Get*SP calls so they don't return invalid objects. Also fixed the ExecutionContext::Has*Scope calls so they don't claim to have a scope if the object representing that scope has been destroyed. Also fixed a think-o in Thread::IsValid which was causing it to return the opposite of the desired value. <rdar://problem/11995490> llvm-svn: 162401
* Remove further outdated "settings" code and also implement a few missing things.Greg Clayton2012-08-221-281/+2
| | | | llvm-svn: 162376
* Reimplemented the code that backed the "settings" in lldb. There were many ↵Greg Clayton2012-08-221-265/+359
| | | | | | | | | | | | | issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
* Add explicit casts to bool in "shared pointer is valid" constructs that ↵Jim Ingham2012-08-111-1/+1
| | | | | | return bool. llvm-svn: 161719
* Removed explicit NULL checks for shared pointersSean Callanan2012-08-091-1/+1
| | | | | | | | | and instead made us use implicit casts to bool. This generated a warning in C++11. <rdar://problem/11930775> llvm-svn: 161559
* Fixed a problem where stepping out would turn intoSean Callanan2012-07-311-2/+10
| | | | | | | | a continue if the unwinder didn't unwind correctly. <rdar://problem/11989668> llvm-svn: 161086
* <rdar://problem/11852100>Greg Clayton2012-07-111-11/+3
| | | | | | The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
* <rdar://problem/11386214>Greg Clayton2012-05-181-0/+8
| | | | | | | | | | | <rdar://problem/11455913> "target symbol add" should flush the cached frames "register write" should flush the thread state in case registers modifications change stack llvm-svn: 157042
* Fix a comment I had incorrectly altered.Jim Ingham2012-05-111-1/+1
| | | | llvm-svn: 156668
* Found one more place where the OkayToDiscard needs to be consulted.Jim Ingham2012-05-111-4/+9
| | | | | | | Also changed the defaults for SBThread::Step* to not delete extant plans. Also added some test cases to test more complex stepping scenarios. llvm-svn: 156667
OpenPOWER on IntegriCloud