summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/ThreadList.cpp
Commit message (Collapse)AuthorAgeFilesLines
* This change introduces a "ExpressionExecutionThread" to the ThreadList. Jim Ingham2016-03-121-0/+37
| | | | | | | | | | | | | | | | | | | Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on behalf of the expression parser was using the currently selected thread. But sometimes, e.g. when we are evaluating breakpoint conditions/commands, we don't select the thread we're running on, we instead set the context for the interpreter, and explicitly pass that to other callers. That wasn't getting communicated to these utility expressions, so they would run on some other thread instead, and that could cause a variety of subtle and hard to reproduce problems. I also went through the commands and cleaned up the use of GetSelectedThread. All those uses should have been trying the thread in the m_exe_ctx belonging to the command object first. It would actually have been pretty hard to get misbehavior in these cases, but for correctness sake it is good to make this usage consistent. <rdar://problem/24978569> llvm-svn: 263326
* Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr ↵Eugene Zelenko2015-12-151-0/+5
| | | | | | | | warnings in some files in source/Target/. Simplify smart pointers checks in conditions. Other minor fixes. llvm-svn: 255598
* Change the null check to an assert.Zachary Turner2015-11-131-1/+3
| | | | llvm-svn: 253092
* Add a null check against the ThreadPlanZachary Turner2015-11-131-1/+1
| | | | | | | | I'm seeing some cases where the ThreadPlan is null. It could be a sign of a valid race condition, but at least we shouldn't crash. llvm-svn: 253086
* Fix TestThreadSpecificBreakpoint.py on Linux after rL252355.Chaoren Lin2015-11-071-1/+5
| | | | | | | | | | | | | | | | | Summary: On Linux, if a thread-specific conditional breakpoint was hit, it won't necessarily be the thread that hit the breakpoint itself that evaluates the conditional expression, so the thread that hit the breakpoint could still be asked to stop, even though it hasn't been allowed to run since the previous stop. Reviewers: sivachandra, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14472 llvm-svn: 252391
* Another optimization to keep down gdb-remote traffic. If we have suspended ↵Jim Ingham2015-11-061-2/+18
| | | | | | | | a thread while running, don't request the thread status when deciding why we stopped. llvm-svn: 252355
* Add an OperatingSystem plugin to support goroutinesRyan Brown2015-09-161-1/+2
| | | | | | | | | | The Go runtime schedules user level threads (goroutines) across real threads. This adds an OS plugin to create memory threads for goroutines. It supports the 1.4 and 1.5 go runtime. Differential Revision: http://reviews.llvm.org/D5871 llvm-svn: 247852
* Fix typos.Bruce Mitchener2015-07-221-2/+2
| | | | | | | | | | | | Summary: Fix a bunch of typos. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11386 llvm-svn: 242856
* Fix up some comments to be more explicit. Remove some long-commented out code.Jim Ingham2015-06-021-0/+1
| | | | llvm-svn: 238862
* Enable debugging of multithreaded programs on Windows.Adrian McCarthy2015-05-181-2/+2
| | | | llvm-svn: 237637
* Reverting r237392 since it broke TestNumThreads on ubuntu builder.Oleksiy Vyalov2015-05-151-2/+2
| | | | llvm-svn: 237415
* Enable multithreaded debugging on Windows.Adrian McCarthy2015-05-141-2/+2
| | | | llvm-svn: 237392
* Move some functions from source/lldb.cpp to Utility.Zachary Turner2015-03-181-0/+1
| | | | | | | | | | Specifically, there were some functions for converting enums to strings and a function for matching a string using a specific matching algorithm. This moves those functions to more appropriate headers in lldb/Utility and updates references to include the new headers. llvm-svn: 232673
* [lldb] Abstract a superclass for a generic thread container.Kuba Brecka2014-09-051-21/+2
| | | | | | | | | Reviewed at http://reviews.llvm.org/D5200 and http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140901/012799.html llvm-svn: 217269
* Fix the behavior when hand-calling a function times out on one thread,Jim Ingham2014-04-081-1/+10
| | | | | | | | | | but by the time we go to halt, it has already stopped by hitting the function end breakpoint. That wasn't being shown to the threads so the Function call thread plan didn't know its job was done. <rdar://problem/16515785> llvm-svn: 205803
* Fixed deadlocks that could occur when using python for breakpoints, ↵Greg Clayton2014-02-131-0/+11
| | | | | | | | | operating system plugins, and other async python usage. <rdar://problem/16054348> <rdar://problem/16040833> llvm-svn: 201372
* Correct logic checking for the first stop IDEd Maste2014-01-171-1/+1
| | | | llvm-svn: 199503
* Fix a bug where if we stop but nobody says there was a reason for the stop, ↵Jim Ingham2014-01-151-5/+19
| | | | | | | | | | | | | we would return control to the user anyway. This was put in to handle monitors that would say there was no stop reason when you first attached to them. But it broke the case where you hit a thread specific breakpoint on many threads, but NOT the one specified in the breakpoint. I work around this by only doing the junky override when the StopID is 0 - i.e. on first attach. This commit also adds a test for thread specific breakpoints. llvm-svn: 199290
* Adding support for setting thread stop state when a process stops.Andrew Kaylor2013-05-101-0/+22
| | | | | | 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-22/+0
| | | | llvm-svn: 181526
* Changed the formerly pure virtual function:Greg Clayton2013-05-091-13/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+22
| | | | llvm-svn: 181482
* Figure out the reply to "PlanExplainsStop" once when we stop and then use ↵Jim Ingham2013-05-081-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-30/+32
| | | | llvm-svn: 181340
* Temporarily reverting r181091 and r181106 due to the vast test breakage on ↵Ashok Thirumurthi2013-05-071-32/+30
| | | | | | | | | | 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-30/+32
| | | | | | | | | | 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-5/+51
| | | | | | | | | | | | | | <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
* Make sure all the threads get a chance to compute their StopInfo's before we ↵Jim Ingham2013-04-161-1/+12
| | | | | | | | | | | start running ShouldStop on the threads, which might destroy information needed to correctly compute another thread's StopInfo. <rdar://problem/13664026> llvm-svn: 179641
* <rdar://problem/13527167>Greg Clayton2013-03-281-0/+4
| | | | | | | | Partial fix for the above radar. Call ThreadList::Clear() in the ThreadList destructor so if any other threads currently have the thread list mutex, we won't destroy the list for them while they are using it. ThreadList::Clear() takes the mutex and clears the thread list contents. llvm-svn: 178257
* <rdar://problem/13521159>Greg Clayton2013-03-271-6/+6
| | | | | | | | 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
* If we stopped but no threads had a reason for stopping, we should tell the ↵Jim Ingham2013-03-211-1/+16
| | | | | | | | user about it rather than continuing. <rdar://problem/13273125> Astris thread status replies for single-core device confuse lldb; lldb resumes execution on attaching llvm-svn: 177670
* <rdar://problem/12976225>Han Ming Ong2013-01-081-0/+23
| | | | | | Checking in the support for doing index ids reservation when given a thread id. llvm-svn: 171904
* Broadcast an event when the selected thread is changed.Jim Ingham2012-12-111-2/+17
| | | | | | <rdar://problem/10976636> llvm-svn: 169810
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-4/+4
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* Don't lock the thread list during ThreadList::ShouldStop. That does tooJim Ingham2012-11-151-7/+20
| | | | | | | much work for this to make sense. Just copy the current thread list and operate on that. Prevents some deadlocks. llvm-svn: 168106
* Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. ↵Greg Clayton2012-09-181-2/+2
| | | | | | Some platforms don't support this modification. llvm-svn: 164148
* Initial check-in of "fancy" inlined stepping. Doesn't do anything useful ↵Jim Ingham2012-09-011-4/+9
| | | | | | | | | 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
* When we are preparing all threads to run, if the overall run state of a ↵Jim Ingham2012-05-311-1/+6
| | | | | | | | thread is "suspended" that should override the thread's thread plan's run state. llvm-svn: 157766
* <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
* First pass at mach-o core file support is in. It currently works for x86_64 Greg Clayton2012-02-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
* Threads now store their "temporary" resume state, so we know whether they ↵Jim Ingham2012-01-311-59/+21
| | | | | | | | | were suspended in the most recent step, and if they weren't allowed to run, don't ask questions about their state unless explicitly requested to do so. llvm-svn: 149443
* Switching back to using std::tr1::shared_ptr. We originally switched awayGreg Clayton2012-01-291-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
* Moved lldb::user_id_t values to be 64 bit. This was going to be needed forGreg Clayton2011-10-191-6/+6
| | | | | | | | | | | process IDs, and thread IDs, but was mainly needed for for the UserID's for Types so that DWARF with debug map can work flawlessly. With DWARF in .o files the type ID was the DIE offset in the DWARF for the .o file which is not unique across all .o files, so now the SymbolFileDWARFDebugMap class will make the .o file index part (the high 32 bits) of the unique type identifier so it can uniquely identify the types. llvm-svn: 142534
* Make the "log enable lldb-step" output easier to parse.Jim Ingham2011-10-151-15/+17
| | | | llvm-svn: 142025
* In ThreadList::GetSelectedThread, handle the case where we have noJason Molenda2011-09-131-0/+2
| | | | | | | valid threads - can happen if attaching to a process fails in a certain way. llvm-svn: 139567
* Move the SourceManager from the Debugger to the Target. That way it can ↵Jim Ingham2011-09-081-4/+11
| | | | | | | | | | store the per-Target default Source File & Line. Set the default Source File & line to main (if it can be found.) at startup. Selecting the current thread & or frame resets the current source file & line, and "source list" as well as the breakpoint command "break set -l <NUM>" will use the current source file. llvm-svn: 139323
* Modify the impl of ThreadList::GetSelectedThread() so that it tries to fetch theJohnny Chen2011-08-251-3/+7
| | | | | | | m_selected_tid thread first, check to see if it is valid (might be null if the thread just exited), and if not select/return the 0th thread instead. llvm-svn: 138591
* Make ThreadList::GetSelectedThread() select and return the 0th thread if ↵Johnny Chen2011-08-251-0/+2
| | | | | | | | there's no currently selected thread. And update the call sites accordingly. llvm-svn: 138577
* Added a new plug-in type: lldb_private::OperatingSystem. The operating system Greg Clayton2011-08-221-0/+17
| | | | | | | | | | | | | | | | | | | | plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
* Fixed the LLDB build so that we can have private types, private enums andGreg Clayton2011-03-241-1/+1
| | | | | | | | public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
OpenPOWER on IntegriCloud