summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/Thread.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* This commit reworks how the thread plan's ShouldStopHere mechanism works, so ↵Jim Ingham2014-03-131-18/+82
| | | | | | | | | | | | | | | that it is useful not only for customizing "step-in" behavior (e.g. step-in doesn't step into code with no debug info), but also the behavior of step-in/step-out and step-over when they step out of the frame they started in. I also added as a proof of concept of this reworking a mode for stepping where stepping out of a frame into a frame with no debug information will continue stepping out till it arrives at a frame that does have debug information. This is useful when you are debugging callback based code where the callbacks are separated from the code that initiated them by some library glue you don't care about, among other things. llvm-svn: 203747
* When a client asks for a queue pending item's extended backtrace,Jason Molenda2014-03-061-2/+2
| | | | | | | | | | | hold a strong pointer to that extended backtrace thread in the Process just like we do for asking a thread's extended backtrace. Also, give extended backtrace threads an invalid ThreadIndexID number. We'll still give them valid thread_id's. Clients who want to know the original thread's IndexID can call GetExtendedBacktraceOriginatingIndexID(). <rdar://problem/16126034> llvm-svn: 203088
* Initial patch for supporting Hexagon DSPDeepak Panickal2014-02-191-0/+1
| | | | llvm-svn: 201665
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-0/+122
| | | | | | | | | | | | The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
* Add a "step-avoid-libraries" setting to complement the "step-avoid-regexp" ↵Jim Ingham2014-01-231-0/+12
| | | | | | setting. llvm-svn: 199943
* <rdar://problem/15172417>Greg Clayton2013-11-131-44/+33
| | | | | | | | | | | | | | | Added two new GDB server packets to debugserver: "QSaveRegisterState" and "QRestoreRegiterState". "QSaveRegisterState" makes the remote GDB server save all register values and it returns a save identifier as an unsigned integer. This packet can be used prior to running expressions to save all registers. All registers can them we later restored with "QRestoreRegiterState:SAVEID" what SAVEID is the integer identifier that was returned from the call to QSaveRegisterState. Cleaned up redundant code in lldb_private::Thread, lldb_private::ThreadPlanCallFunction. Moved the lldb_private::Thread::RegisterCheckpoint into its own header file and it is now in the lldb_private namespace. Trimmed down the RegisterCheckpoint class to omit stuff that wasn't used (the stack ID). Added a few new virtual methods to lldb_private::RegisterContext that allow subclasses to efficiently save/restore register states and changed the RegisterContextGDBRemote to take advantage of these new calls. llvm-svn: 194621
* Log failure to restore thread state in ThreadPlanCallFunction::DoTakedownEd Maste2013-11-121-2/+1
| | | | | | In order to help track down llvm.org/pr17226. llvm-svn: 194487
* This patch does a couple of things. Jim Ingham2013-11-071-27/+0
| | | | | | | | | | | | | | | | | | | | | | It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-21/+21
| | | | | | | | | | pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-021-21/+21
| | | | | | | | | | | | | | | | | | | | | defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods. Update all callers to use Frame*/Frame& instead of pointers to StackFrames. This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet. I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point. <rdar://problem/15314068> llvm-svn: 193907
* Mark the selected frame of the selected thread in backtraces.Jim Ingham2013-10-181-3/+11
| | | | | | <rdar://problem/15252474> llvm-svn: 192989
* Make sure the CallFunction Thread plans don't try to do DoTakedown if their ↵Jim Ingham2013-10-181-3/+9
| | | | | | | | | | thread has gone away by the time they get around to doing it. <rdar://problem/15245544> llvm-svn: 192987
* Added support for reading thread-local storage variables, as defined using ↵Richard Mitton2013-10-171-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the __thread modifier. To make this work this patch extends LLDB to: - Explicitly track the link_map address for each module. This is effectively the module handle, not sure why it wasn't already being stored off anywhere. As an extension later, it would be nice if someone were to add support for printing this as part of the modules list. - Allow reading the per-thread data pointer via ptrace. I have added support for Linux here. I'll be happy to add support for FreeBSD once this is reviewed. OS X does not appear to have __thread variables, so maybe we don't need it there. Windows support should eventually be workable along the same lines. - Make DWARF expressions track which module they originated from. - Add support for the DW_OP_GNU_push_tls_address DWARF opcode, as generated by gcc and recent versions of clang. Earlier versions of clang (such as 3.2, which is default on Ubuntu right now) do not generate TLS debug info correctly so can not be supported here. - Understand the format of the pthread DTV block. This is where it gets tricky. We have three basic options here: 1) Call "dlinfo" or "__tls_get_addr" on the inferior and ask it directly. However this won't work on core dumps, and generally speaking it's not a good idea for the debugger to call functions itself, as it has the potential to not work depending on the state of the target. 2) Use libthread_db. This is what GDB does. However this option requires having a version of libthread_db on the host cross-compiled for each potential target. This places a large burden on the user, and would make it very hard to cross-debug from Windows to Linux, for example. Trying to build a library intended exclusively for one OS on a different one is not pleasant. GDB sidesteps the problem and asks the user to figure it out. 3) Parse the DTV structure ourselves. On initial inspection this seems to be a bad option, as the DTV structure (the format used by the runtime to manage TLS data) is not in fact a kernel data structure, it is implemented entirely in useerland in libc. Therefore the layout of it's fields are version and OS dependent, and are not standardized. However, it turns out not to be such a problem. All OSes use basically the same algorithm (a per-module lookup table) as detailed in Ulrich Drepper's TLS ELF ABI document, so we can easily write code to decode it ourselves. The only question therefore is the exact field layouts required. Happily, the implementors of libpthread expose the structure of the DTV via metadata exported as symbols from the .so itself, designed exactly for this kind of thing. So this patch simply reads that metadata in, and re-implements libthread_db's algorithm itself. We thereby get cross-platform TLS lookup without either requiring third-party libraries, while still being independent of the version of libpthread being used. Test case included. llvm-svn: 192922
* POSIX RegisterContext for mips64Ed Maste2013-10-101-0/+1
| | | | | | | | | Based on the POSIX x86_64 register context. This is sufficient for opening a mips64 (big endian) core file. Subsequent changes will connect the disassembler, dynamic loader support, ABI, etc. Review: http://llvm-reviews.chandlerc.com/D1873 llvm-svn: 192335
* Added a 'jump' command, similar to GDBs.Richard Mitton2013-09-121-0/+73
| | | | | | | | | This allows the PC to be directly changed to a different line. It's similar to the example python script in examples/python/jump.py, except implemented as a builtin. Also this version will track the current function correctly even if the target line resolves to multiple addresses. (e.g. debugging a templated function) llvm-svn: 190572
* <rdar://problem/14526890>Greg Clayton2013-07-301-0/+13
| | | | | | Fixed a crasher when using memory threads where a thread is sticking around too long and was causing problems when it didn't have a thread plan. llvm-svn: 187395
* This commit does two things. One, it converts the return value of the ↵Jim Ingham2013-07-181-22/+22
| | | | | | | | | | | | | QueueThreadPlanXXX plan providers from a "ThreadPlan *" to a "lldb::ThreadPlanSP". That was needed to fix a bug where the ThreadPlanStepInRange wasn't checking with its sub-plans to make sure they succeed before trying to proceed further. If the sub-plan failed and as a result didn't make any progress, you could end up retrying the same failing algorithm in an infinite loop. <rdar://problem/14043602> llvm-svn: 186618
* Huge change to clean up types.Greg Clayton2013-07-111-4/+3
| | | | | | | | A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
* Add some useful logging for tracking thread matching problems.Jim Ingham2013-06-221-7/+15
| | | | llvm-svn: 184619
* Fix various build warnings.Matt Kopec2013-06-031-1/+1
| | | | llvm-svn: 183140
* Add ${ansi.XX} parsing to lldb prompt, use-color setting, and -no-use-colors ↵Michael Sartain2013-05-231-3/+1
| | | | | | | | | | command line options. settings set use-color [false|true] settings set prompt "${ansi.bold}${ansi.fg.green}(lldb)${ansi.normal} " also "--no-use-colors" on the command prompt llvm-svn: 182609
* Added a test case that verifies that LLDB can debug across a process ↵Greg Clayton2013-05-211-0/+3
| | | | | | | | 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
* Fix inline stepping test case on Linux because ↵Daniel Malea2013-05-141-24/+19
| | | | | | | | | | | | Thread::ThreadStoppedForAReason ignored virtual steps. - add IsVirtualStep() virtual function to ThreadPlan, and implement it for ThreadPlanStepInRange - make GetPrivateStopReason query the current thread plan for a virtual stop to decide if the current stop reason needs to be preserved - remove extra check for an existing process in GetPrivateStopReason llvm-svn: 181795
* 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
OpenPOWER on IntegriCloud