summaryrefslogtreecommitdiffstats
path: root/lldb/source/API/SBThread.cpp
Commit message (Collapse)AuthorAgeFilesLines
* This checkin is the first step in making the lldb thread stepping mechanism ↵Jim Ingham2014-09-291-2/+67
| | | | | | | | | | | | more accessible from the user level. It adds the ability to invent new stepping modes implemented by python classes, and to view the current thread plan stack and to some extent alter it. I haven't gotten to documentation or tests yet. But this should not cause any behavior changes if you don't use it, so its safe to check it in now and work on it incrementally. llvm-svn: 218642
* Initial merge of some of the iOS 8 / Mac OS X Yosemite specificJason Molenda2014-06-131-0/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lldb support. I'll be doing more testing & cleanup but I wanted to get the initial checkin done. This adds a new SBExpressionOptions::SetLanguage API for selecting a language of an expression. I added adds a new SBThread::GetInfoItemByPathString for retriving information about a thread from that thread's StructuredData. I added a new StructuredData class for representing key-value/array/dictionary information (e.g. JSON formatted data). Helper functions to read JSON and create a StructuredData object, and to print a StructuredData object in JSON format are included. A few Cocoa / Cocoa Touch data formatters were updated by Enrico to track changes in iOS 8 / Yosemite. Before we query a thread's extended information, the system runtime may provide hints to the remote debug stub that it will use to retrieve values out of runtime structures. I added a new SystemRuntime method AddThreadExtendedInfoPacketHints which allows the SystemRuntime to add key-value type data to the initial request that we send to the remote stub. The thread-format formatter string can now retrieve values out of a thread's extended info structured data. The default thread-format string picks up two of these - thread.info.activity.name and thread.info.trace_messages. I added a new "jThreadExtendedInfo" packet in debugserver; I will add documentation to the lldb-gdb-remote.txt doc soon. It accepts JSON formatted arguments (most importantly, "thread":threadnum) and it returns a variety of information regarding the thread to lldb in JSON format. This JSON return is scanned into a StructuredData object that is associated with the thread; UI layers can query the thread's StructuredData to see if key-values are present, and if so, show them to the user. These key-values are likely to be specific to different targets with some commonality among many targets. For instance, many targets will be able to advertise the pthread_t value for a thread. I added an initial rough cut of "thread info" command which will print the information about a thread from the jThreadExtendedInfo result. I need to do more work to make this format reasonably. Han Ming added calls into the pmenergy and pmsample libraries if debugserver is run on Mac OS X Yosemite to get information about the inferior's power use. I added support to debugserver for gathering the Genealogy information about threads, if it exists, and returning it in the jThreadExtendedInfo JSON result. llvm-svn: 210874
* Add a new SBThread::SafeToCallFunctions API; this calls over toJason Molenda2014-05-131-0/+9
| | | | | | | | | | the SystemRuntime to check if a thread will have any problems performing an inferior function call so the driver can skip making that function call on that thread. Often the function call can be executed on another thread instead. <rdar://problem/16777874> llvm-svn: 208732
* Add a new SBThread::GetQueue() method to get the queue that is Jason Molenda2014-04-251-0/+37
| | | | | | | | | | currently associated with a given thread, on relevant targets. Change the queue detection code to verify that the queues associated with all live threads are included in the list. <rdar://problem/16411314> llvm-svn: 207160
* Fixed SBThread.GetStopReasonDataAtIndex() to correctly return breakpoint ↵Greg Clayton2014-04-111-1/+1
| | | | | | | | location ID. Patch from Vyacheslav Karpukhin. llvm-svn: 206040
* sweep up -Wformat warnings from gccSaleem Abdulrasool2014-04-041-99/+147
| | | | | | | This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
* Make the fail messagesJim Ingham2014-04-031-1/+2
| | | | llvm-svn: 205497
* This commit reworks how the thread plan's ShouldStopHere mechanism works, so ↵Jim Ingham2014-03-131-4/+10
| | | | | | | | | | | | | | | 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
* Add API logging to the SBQueue/SBQueueItem/SBThread calls.Jason Molenda2014-03-081-0/+4
| | | | llvm-svn: 203330
* Add logging for the SB API which creates extendedJason Molenda2013-11-191-5/+15
| | | | | | | | | | threads. Take a stab at fixing the too-soon freeing of the extended backtrace thread list in Process. <rdar://problem/15496603> llvm-svn: 195104
* Add a new SBThread::GetExtendedBacktraceOriginatingIndexID() methodJason Molenda2013-11-161-0/+9
| | | | | | | | | | (and same thing to Thread base class) which can be used when looking at an ExtendedBacktrace thread; it will try to find the IndexID() of the original thread that was executing this backtrace when it was recorded. If lldb can't find a record of that thread, it will return the same value as IndexID() for the ExtendedBacktrace thread. llvm-svn: 194912
* Change SBThread::GetExtendedBacktrace toJason Molenda2013-11-121-3/+2
| | | | | | | SBThread::GetExtendedBacktraceThread to make it more clear what is being returned. llvm-svn: 194531
* The Threads created when requesting extended backtraces need to be owned byJason Molenda2013-11-111-6/+12
| | | | | | | | something; add a new ExtendedThreadList to Process where they can be retained for the duration of a public stop. <rdar://problem/15314068> llvm-svn: 194366
* Add History subclasses for Thread, Unwind, RegisterContext.Jason Molenda2013-11-081-1/+2
| | | | | | | | Still working out some of the details of these classes but I wanted to get the overall structure checked in. <rdar://problem/15314068> llvm-svn: 194245
* Rename extended backtrace methods to take out the "ThreadOrigin"Jason Molenda2013-11-061-3/+3
| | | | | | | bit from the method names. <rdar://problem/15314369> llvm-svn: 194122
* Add a new GetThreadOriginExtendedBacktrace method to the Jason Molenda2013-11-061-0/+36
| | | | | | | SystemRuntime and SBThread classes. <rdar://problem/15314369> llvm-svn: 194111
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-7/+7
| | | | | | | | | | 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-7/+7
| | | | | | | | | | | | | | | | | | | | | 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
* Expose the Thread::GetQueueID() method through the SBThread API, similar toJason Molenda2013-10-211-0/+28
| | | | | | the existing SBThread::GetQueueName() method. llvm-svn: 193132
* Added a 'jump' command, similar to GDBs.Richard Mitton2013-09-121-0/+25
| | | | | | | | | 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
* This commit does two things. One, it converts the return value of the ↵Jim Ingham2013-07-181-21/+21
| | | | | | | | | | | | | 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
* Adding new Python API function to check for stopped threads.Andrew Kaylor2013-04-151-0/+10
| | | | llvm-svn: 179577
* <rdar://problem/13521159>Greg Clayton2013-03-271-23/+23
| | | | | | | | 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
* the log entry for SBThread::GetProcess() would not include the pointer to ↵Enrico Granata2013-02-281-3/+1
| | | | | | the process because we were using the value of the (otherwise unused) process_sp - instead of fetching the SP from sb_process llvm-svn: 176231
* Adding eStopReasonThreadExiting and fixing the handling of this state on Linux.Andrew Kaylor2012-12-201-0/+9
| | | | llvm-svn: 170800
* Fixed a few bugs in the "step in" thread plan logic.Jim Ingham2012-12-121-14/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+10
| | | | | | 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-2/+2
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* Change the Thread constructor over to take a Process& rather than a ↵Jim Ingham2012-10-101-0/+41
| | | | | | | | | | | | | 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
* <rdar://problem/9959501>Greg Clayton2012-09-251-3/+1
| | | | | | More KDP debugging process. We can not set breakpoints, hit them, resume, step and detach while running. llvm-svn: 164584
* Remove a duplicate frame_sp local that was shadowing the one we copied the ↵Jim Ingham2012-09-141-1/+0
| | | | | | | | incoming SBFrame into. <rdar://problem/12304255> llvm-svn: 163943
* SBThread::StepOut and SBThread::StepOutOfFrame should both run all threads.Jim Ingham2012-09-141-2/+2
| | | | llvm-svn: 163938
* SBThread::StepOverUntil should run all threads. It is running to ↵Jim Ingham2012-09-141-1/+1
| | | | | | breakpoints, so running one thread is likely to cause the target to stall. llvm-svn: 163924
* Make the unwinding of the stack part of "thread return" work, and add the ↵Jim Ingham2012-09-141-3/+3
| | | | | | thread return command. llvm-svn: 163867
* Start at getting "thread return" working. Doesn't work yet.Jim Ingham2012-09-121-0/+23
| | | | llvm-svn: 163670
* Rework how the API mutex is acquired when filling out an ExecutionContext ↵Jim Ingham2012-08-221-37/+53
| | | | | | | | | | | | | | | | | 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
* Found one more place where the OkayToDiscard needs to be consulted.Jim Ingham2012-05-111-6/+6
| | | | | | | 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
* Clean up the usage of "MasterPlan" status in ThreadPlans. Only ↵Jim Ingham2012-05-031-115/+100
| | | | | | | | | | | | | | | user-initiated plans should be MasterPlans that want to stay on the plan stack. So make all plans NOT MasterPlans by default and then have the SB API's and the CommandObjectThread step commands set this explicitly. Also added a "clean up" phase to the Thread::ShouldStop so that if plans get stranded on the stack, we can remove them. This is done by adding an IsPlanStale method to the thread plans, and if the plan can know that it is no longer relevant, it returns true, and the plan and its sub-plans will get discarded. llvm-svn: 156101
* Added logging when API calls try to do something that shouldn't be done when ↵Greg Clayton2012-04-061-9/+93
| | | | | | | | the process is stopped by having logging calls that end with "error: process is running". Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more. llvm-svn: 154160
* Added a new Host class: ReadWriteLockGreg Clayton2012-04-051-194/+241
| | | | | | | | | | | | This abstracts read/write locks on the current host system. It is currently backed by pthread_rwlock_t objects so it should work on all unix systems. We also need a way to control multi-threaded access to the process through the public API when it is running. For example it isn't a good idea to try and get stack frames while the process is running. To implement this, the lldb_private::Process class now contains a ReadWriteLock member variable named m_run_lock which is used to control the public process state. The public process state represents the state of the process as the client knows it. The private is used to control the actual current process state. So the public state of the process can be stopped, yet the private state can be running when evaluating an expression for example. Adding the read/write lock where readers are clients that want the process to stay stopped, and writers are clients that run the process, allows us to accurately control multi-threaded access to the process. Switched the SBThread and SBFrame over to us shared pointers to the ExecutionContextRef class instead of making their own class to track this. This fixed an issue with assigning on SBFrame to another and will also centralize the code that tracks weak references to execution context objects into one location. llvm-svn: 154099
* Fixed some space formatting.Greg Clayton2012-03-281-7/+7
| | | | llvm-svn: 153582
* <rdar://problem/10103468>Greg Clayton2012-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
* Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptrGreg Clayton2012-02-211-173/+179
| | | | | | | | | | | | | | | | | objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
* SBFrame is now threadsafe using some extra tricks. One issue is that stackGreg Clayton2012-01-301-20/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
* Removed the "lldb-forward-rtti.h" header file as it was designed to containGreg Clayton2012-01-301-190/+192
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | all RTTI types, and since we don't use RTTI anymore since clang and llvm don't we don't really need this header file. All shared pointer definitions have been moved into "lldb-forward.h". Defined std::tr1::weak_ptr definitions for all of the types that inherit from enable_shared_from_this() in "lldb-forward.h" in preparation for thread hardening our public API. The first in the thread hardening check-ins. First we start with SBThread. We have issues in our lldb::SB API right now where if you have one object that is being used by two threads we have a race condition. Consider the following code: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 if (m_opaque_sp) 6 { 7 result = m_opaque_sp->DoSomething(); 8 } 9 return result; 10 } And now this happens: Thread 1 enters any SBThread function and checks its m_opaque_sp and is about to execute the code on line 7 but hasn't yet Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear() and clears the contents of the shared pointer member Thread 1 now crashes when it resumes. The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this function would look like: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 ThreadSP thread_sp(m_opaque_wp.lock()); 6 if (thread_sp) 7 { 8 result = m_opaque_sp->DoSomething(); 9 } 10 return result; 11 } Now we have a solid thread safe API where we get a local copy of our thread shared pointer from our weak_ptr and then we are guaranteed it can't go away during our function. So lldb::SBThread has been thread hardened, more checkins to follow shortly. llvm-svn: 149218
* Fixed code rot pointed out by Jim.Johnny Chen2011-12-171-4/+2
| | | | | | SBThread::GetStopReasonDataCount/GetStopReasonDataAtIndex() need to handle eStopReasonWatchpoint. llvm-svn: 146812
* Add the ability to capture the return value in a thread's stop info, and ↵Jim Ingham2011-12-171-2/+26
| | | | | | | | | | | | | print it as part of the thread format output. Currently this is only done for the ThreadPlanStepOut. Add a convenience API ABI::GetReturnValueObject. Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than trying to hand out one of its subsidiary object's pointers. That way this will always be good. llvm-svn: 146806
* Process IDs (lldb::pid_t) and thread IDs (lldb::tid_t) are now 64 bit. This Greg Clayton2011-12-011-1/+1
| | | | | | | | will allow us to represent a process/thread ID using a pointer for the OS plug-ins where they might want to represent the process or thread ID using the address of the process or thread structure. llvm-svn: 145644
* <rdar://problem/10126482>Greg Clayton2011-11-131-3/+4
| | | | | | | | | | | | | | | Fixed an issues with the SBType and SBTypeMember classes: - Fixed SBType to be able to dump itself from python - Fixed SBType::GetNumberOfFields() to return the correct value for objective C interfaces - Fixed SBTypeMember to be able to dump itself from python - Fixed the SBTypeMember ability to get a field offset in bytes (the value being returned was wrong) - Added the SBTypeMember ability to get a field offset in bits Cleaned up a lot of the Stream usage in the SB API files. llvm-svn: 144493
OpenPOWER on IntegriCloud