maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/API/SBThread.cpp

1355 lines
44 KiB
C++
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//===-- SBThread.cpp --------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
Fix Linux build warnings due to redefinition of macros: - 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
2012-12-05 08:20:57 +08:00
#include "lldb/lldb-python.h"
And some more include line fixes. llvm-svn: 105704
2010-06-09 15:44:37 +08:00
#include "lldb/API/SBThread.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/API/SBSymbolContext.h"
#include "lldb/API/SBFileSpec.h"
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
#include "lldb/API/SBStream.h"
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
#include "lldb/Breakpoint/BreakpointLocation.h"
Very large changes that were needed in order to allow multiple connections to the debugger from GUI windows. Previously there was one global debugger instance that could be accessed that had its own command interpreter and current state (current target/process/thread/frame). When a GUI debugger was attached, if it opened more than one window that each had a console window, there were issues where the last one to setup the global debugger object won and got control of the debugger. To avoid this we now create instances of the lldb_private::Debugger that each has its own state: - target list for targets the debugger instance owns - current process/thread/frame - its own command interpreter - its own input, output and error file handles to avoid conflicts - its own input reader stack So now clients should call: SBDebugger::Initialize(); // (static function) SBDebugger debugger (SBDebugger::Create()); // Use which ever file handles you wish debugger.SetErrorFileHandle (stderr, false); debugger.SetOutputFileHandle (stdout, false); debugger.SetInputFileHandle (stdin, true); // main loop SBDebugger::Terminate(); // (static function) SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to ensure nothing gets destroyed too early when multiple clients might be attached. Cleaned up the command interpreter and the CommandObject and all subclasses to take more appropriate arguments. llvm-svn: 106615
2010-06-23 09:19:29 +08:00
#include "lldb/Core/Debugger.h"
Adding new Python API function to check for stopped threads. llvm-svn: 179577
2013-04-16 07:33:53 +08:00
#include "lldb/Core/State.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/Stream.h"
#include "lldb/Core/StreamFile.h"
Very large changes that were needed in order to allow multiple connections to the debugger from GUI windows. Previously there was one global debugger instance that could be accessed that had its own command interpreter and current state (current target/process/thread/frame). When a GUI debugger was attached, if it opened more than one window that each had a console window, there were issues where the last one to setup the global debugger object won and got control of the debugger. To avoid this we now create instances of the lldb_private::Debugger that each has its own state: - target list for targets the debugger instance owns - current process/thread/frame - its own command interpreter - its own input, output and error file handles to avoid conflicts - its own input reader stack So now clients should call: SBDebugger::Initialize(); // (static function) SBDebugger debugger (SBDebugger::Create()); // Use which ever file handles you wish debugger.SetErrorFileHandle (stderr, false); debugger.SetOutputFileHandle (stdout, false); debugger.SetInputFileHandle (stdin, true); // main loop SBDebugger::Terminate(); // (static function) SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to ensure nothing gets destroyed too early when multiple clients might be attached. Cleaned up the command interpreter and the CommandObject and all subclasses to take more appropriate arguments. llvm-svn: 106615
2010-06-23 09:19:29 +08:00
#include "lldb/Interpreter/CommandInterpreter.h"
Add a new GetThreadOriginExtendedBacktrace method to the SystemRuntime and SBThread classes. <rdar://problem/15314369> llvm-svn: 194111
2013-11-06 08:04:44 +08:00
#include "lldb/Target/SystemRuntime.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Target/Thread.h"
#include "lldb/Target/Process.h"
#include "lldb/Symbol/SymbolContext.h"
#include "lldb/Symbol/CompileUnit.h"
Abtracted the old "lldb_private::Thread::StopInfo" into an abtract class. This will allow debugger plug-ins to make any instance of "lldb_private::StopInfo" that can completely describe any stop reason. It also provides a framework for doing intelligent things with the stop info at important times in the lifetime of the inferior. Examples include the signal stop info in StopInfoUnixSignal. It will check with the process to see that the current action is for the signal. These actions include wether to stop for the signal, wether the notify that the signal was hit, and wether to pass the signal along to the inferior process. The StopInfoUnixSignal class overrides the "ShouldStop()" method of StopInfo and this allows the stop info to determine if it should stop at the signal or continue the process. StopInfo subclasses must override the following functions: virtual lldb::StopReason GetStopReason () const = 0; virtual const char * GetDescription () = 0; StopInfo subclasses can override the following functions: // If the subclass returns "false", the inferior will resume. The default // version of this function returns "true" which means the default stop // info will stop the process. The breakpoint subclass will check if // the breakpoint wants us to stop by calling any installed callback on // the breakpoint, and also checking if the breakpoint is for the current // thread. Signals will check if they should stop based off of the // UnixSignal settings in the process. virtual bool ShouldStop (Event *event_ptr); // Sublasses can state if they want to notify the debugger when "ShouldStop" // returns false. This would be handy for breakpoints where you want to // log information and continue and is also used by the signal stop info // to notify that a signal was received (after it checks with the process // signal settings). virtual bool ShouldNotify (Event *event_ptr) { return false; } // Allow subclasses to do something intelligent right before we resume. // The signal class will figure out if the signal should be propagated // to the inferior process and pass that along to the debugger plug-ins. virtual void WillResume (lldb::StateType resume_state) { // By default, don't do anything } The support the Mach exceptions was moved into the lldb/source/Plugins/Process/Utility folder and now doesn't polute the lldb_private::Thread class with platform specific code. llvm-svn: 110184
2010-08-04 09:40:35 +08:00
#include "lldb/Target/StopInfo.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Target/Target.h"
#include "lldb/Target/ThreadPlan.h"
#include "lldb/Target/ThreadPlanStepInstruction.h"
#include "lldb/Target/ThreadPlanStepOut.h"
#include "lldb/Target/ThreadPlanStepRange.h"
#include "lldb/Target/ThreadPlanStepInRange.h"
And some more include line fixes. llvm-svn: 105704
2010-06-09 15:44:37 +08:00
#include "lldb/API/SBAddress.h"
#include "lldb/API/SBDebugger.h"
Change the Thread constructor over to take a Process& rather than a 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
2012-10-11 02:32:14 +08:00
#include "lldb/API/SBEvent.h"
Add the ability to capture the return value in a thread's stop info, and 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
2011-12-17 09:35:57 +08:00
#include "lldb/API/SBFrame.h"
And some more include line fixes. llvm-svn: 105704
2010-06-09 15:44:37 +08:00
#include "lldb/API/SBProcess.h"
Add the ability to capture the return value in a thread's stop info, and 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
2011-12-17 09:35:57 +08:00
#include "lldb/API/SBValue.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
using namespace lldb;
using namespace lldb_private;
Change the Thread constructor over to take a Process& rather than a 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
2012-10-11 02:32:14 +08:00
const char *
SBThread::GetBroadcasterClassName ()
{
return Thread::GetStaticBroadcasterClass().AsCString();
}
Cleaned up the API logging a lot more to reduce redundant information and keep the file size a bit smaller. Exposed SBValue::GetExpressionPath() so SBValue users can get an expression path for their values. llvm-svn: 117851
2010-10-31 11:01:06 +08:00
//----------------------------------------------------------------------
// Constructors
//----------------------------------------------------------------------
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBThread::SBThread () :
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
m_opaque_sp (new ExecutionContextRef())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
}
SBThread::SBThread (const ThreadSP& lldb_object_sp) :
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
m_opaque_sp (new ExecutionContextRef(lldb_object_sp))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
}
Fixed the copy constructor for SBThread. llvm-svn: 117825
2010-10-31 02:26:59 +08:00
SBThread::SBThread (const SBThread &rhs) :
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
m_opaque_sp (new ExecutionContextRef(*rhs.m_opaque_sp))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Cleaned up the API logging a lot more to reduce redundant information and keep the file size a bit smaller. Exposed SBValue::GetExpressionPath() so SBValue users can get an expression path for their values. llvm-svn: 117851
2010-10-31 11:01:06 +08:00
//----------------------------------------------------------------------
// Assignment operator
//----------------------------------------------------------------------
const lldb::SBThread &
SBThread::operator = (const SBThread &rhs)
{
if (this != &rhs)
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
*m_opaque_sp = *rhs.m_opaque_sp;
Cleaned up the API logging a lot more to reduce redundant information and keep the file size a bit smaller. Exposed SBValue::GetExpressionPath() so SBValue users can get an expression path for their values. llvm-svn: 117851
2010-10-31 11:01:06 +08:00
return *this;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//----------------------------------------------------------------------
// Destructor
//----------------------------------------------------------------------
SBThread::~SBThread()
{
}
bool
SBThread::IsValid() const
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
return m_opaque_sp->GetThreadSP().get() != NULL;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added "void Clear();" methods to SBDebugger, SBTarget and SBThread so they can release their shared pointers. llvm-svn: 109882
2010-07-31 04:12:55 +08:00
void
SBThread::Clear ()
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
m_opaque_sp->Clear();
Added "void Clear();" methods to SBDebugger, SBTarget and SBThread so they can release their shared pointers. llvm-svn: 109882
2010-07-31 04:12:55 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StopReason
SBThread::GetStopReason()
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
StopReason reason = eStopReasonInvalid;
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
{
<rdar://problem/9959501> More KDP debugging process. We can not set breakpoints, hit them, resume, step and detach while running. llvm-svn: 164584
2012-09-25 10:40:06 +08:00
return exe_ctx.GetThreadPtr()->GetStopReason();
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
}
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
else
{
if (log)
log->Printf ("SBThread(%p)::GetStopReason() => error: process is running", exe_ctx.GetThreadPtr());
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
log->Printf ("SBThread(%p)::GetStopReason () => %s", exe_ctx.GetThreadPtr(),
Clean up the API logging code: - Try to reduce logging to one line per function call instead of tw - Put all arguments & their values into log for calls - Add 'this' parameter information to function call logging, making it show the appropriate internal pointer (this.obj, this.sp, this.ap...) - Clean up some return values - Remove logging of constructors that construct empty objects - Change '==>' to '=>' for showing result values... - Fix various minor bugs - Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments... llvm-svn: 117417
2010-10-27 07:49:36 +08:00
Thread::StopReasonAsCString (reason));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
return reason;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
size_t
SBThread::GetStopReasonDataCount ()
{
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
StopInfoSP stop_info_sp = exe_ctx.GetThreadPtr()->GetStopInfo ();
if (stop_info_sp)
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
StopReason reason = stop_info_sp->GetStopReason();
switch (reason)
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonInvalid:
case eStopReasonNone:
case eStopReasonTrace:
<rdar://problem/12649160> Added the ability to debug through your process exec'ing itself to the same architecture. llvm-svn: 169340
2012-12-05 08:16:59 +08:00
case eStopReasonExec:
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonPlanComplete:
Adding eStopReasonThreadExiting and fixing the handling of this state on Linux. llvm-svn: 170800
2012-12-21 07:08:03 +08:00
case eStopReasonThreadExiting:
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
// There is no data for these stop reasons.
return 0;
case eStopReasonBreakpoint:
{
break_id_t site_id = stop_info_sp->GetValue();
lldb::BreakpointSiteSP bp_site_sp (exe_ctx.GetProcessPtr()->GetBreakpointSiteList().FindByID (site_id));
if (bp_site_sp)
return bp_site_sp->GetNumberOfOwners () * 2;
else
return 0; // Breakpoint must have cleared itself...
}
break;
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonWatchpoint:
return 1;
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonSignal:
return 1;
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonException:
return 1;
}
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
}
}
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
else
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
if (log)
log->Printf ("SBThread(%p)::GetStopReasonDataCount() => error: process is running", exe_ctx.GetThreadPtr());
}
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
}
return 0;
}
uint64_t
SBThread::GetStopReasonDataAtIndex (uint32_t idx)
{
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
Thread *thread = exe_ctx.GetThreadPtr();
StopInfoSP stop_info_sp = thread->GetStopInfo ();
if (stop_info_sp)
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
StopReason reason = stop_info_sp->GetStopReason();
switch (reason)
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonInvalid:
case eStopReasonNone:
case eStopReasonTrace:
<rdar://problem/12649160> Added the ability to debug through your process exec'ing itself to the same architecture. llvm-svn: 169340
2012-12-05 08:16:59 +08:00
case eStopReasonExec:
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonPlanComplete:
Adding eStopReasonThreadExiting and fixing the handling of this state on Linux. llvm-svn: 170800
2012-12-21 07:08:03 +08:00
case eStopReasonThreadExiting:
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
// There is no data for these stop reasons.
return 0;
case eStopReasonBreakpoint:
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
break_id_t site_id = stop_info_sp->GetValue();
lldb::BreakpointSiteSP bp_site_sp (exe_ctx.GetProcessPtr()->GetBreakpointSiteList().FindByID (site_id));
if (bp_site_sp)
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
uint32_t bp_index = idx / 2;
BreakpointLocationSP bp_loc_sp (bp_site_sp->GetOwnerAtIndex (bp_index));
if (bp_loc_sp)
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
if (bp_index & 1)
{
// Odd idx, return the breakpoint location ID
return bp_loc_sp->GetID();
}
else
{
// Even idx, return the breakpoint ID
return bp_loc_sp->GetBreakpoint().GetID();
}
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
}
}
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
return LLDB_INVALID_BREAK_ID;
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
}
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
break;
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonWatchpoint:
return stop_info_sp->GetValue();
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonSignal:
return stop_info_sp->GetValue();
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonException:
return stop_info_sp->GetValue();
}
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
}
}
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
else
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
if (log)
log->Printf ("SBThread(%p)::GetStopReasonDataAtIndex() => error: process is running", exe_ctx.GetThreadPtr());
}
Added the ability to get more information on the SBThread's stop reason by being able to get the data count and data. Each thread stop reason has one or more data words that can help describe the stop. To do this I added: size_t SBThread::GetStopReasonDataCount(); uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx); llvm-svn: 119720
2010-11-19 02:52:36 +08:00
}
return 0;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
size_t
SBThread::GetStopDescription (char *dst, size_t dst_len)
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
StopInfoSP stop_info_sp = exe_ctx.GetThreadPtr()->GetStopInfo ();
if (stop_info_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
const char *stop_desc = stop_info_sp->GetDescription();
if (stop_desc)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
if (log)
log->Printf ("SBThread(%p)::GetStopDescription (dst, dst_len) => \"%s\"",
exe_ctx.GetThreadPtr(), stop_desc);
if (dst)
return ::snprintf (dst, dst_len, "%s", stop_desc);
else
{
// NULL dst passed in, return the length needed to contain the description
return ::strlen (stop_desc) + 1; // Include the NULL byte for size
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
else
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
size_t stop_desc_len = 0;
switch (stop_info_sp->GetStopReason())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonTrace:
case eStopReasonPlanComplete:
{
static char trace_desc[] = "step";
stop_desc = trace_desc;
stop_desc_len = sizeof(trace_desc); // Include the NULL byte for size
}
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonBreakpoint:
{
static char bp_desc[] = "breakpoint hit";
stop_desc = bp_desc;
stop_desc_len = sizeof(bp_desc); // Include the NULL byte for size
}
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonWatchpoint:
{
static char wp_desc[] = "watchpoint hit";
stop_desc = wp_desc;
stop_desc_len = sizeof(wp_desc); // Include the NULL byte for size
}
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonSignal:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
stop_desc = exe_ctx.GetProcessPtr()->GetUnixSignals ().GetSignalAsCString (stop_info_sp->GetValue());
if (stop_desc == NULL || stop_desc[0] == '\0')
{
static char signal_desc[] = "signal";
stop_desc = signal_desc;
stop_desc_len = sizeof(signal_desc); // Include the NULL byte for size
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
case eStopReasonException:
{
char exc_desc[] = "exception";
stop_desc = exc_desc;
stop_desc_len = sizeof(exc_desc); // Include the NULL byte for size
}
break;
Merged Eli Friedman's linux build changes where he added Makefile files that enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
2010-07-10 04:39:50 +08:00
<rdar://problem/12649160> Added the ability to debug through your process exec'ing itself to the same architecture. llvm-svn: 169340
2012-12-05 08:16:59 +08:00
case eStopReasonExec:
{
char exc_desc[] = "exec";
stop_desc = exc_desc;
stop_desc_len = sizeof(exc_desc); // Include the NULL byte for size
}
break;
Adding eStopReasonThreadExiting and fixing the handling of this state on Linux. llvm-svn: 170800
2012-12-21 07:08:03 +08:00
case eStopReasonThreadExiting:
{
char limbo_desc[] = "thread exiting";
stop_desc = limbo_desc;
stop_desc_len = sizeof(limbo_desc);
}
break;
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
default:
break;
}
if (stop_desc && stop_desc[0])
{
if (log)
log->Printf ("SBThread(%p)::GetStopDescription (dst, dst_len) => '%s'",
exe_ctx.GetThreadPtr(), stop_desc);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
if (dst)
return ::snprintf (dst, dst_len, "%s", stop_desc) + 1; // Include the NULL byte
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
if (stop_desc_len == 0)
stop_desc_len = ::strlen (stop_desc) + 1; // Include the NULL byte
return stop_desc_len;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
else
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
if (log)
log->Printf ("SBThread(%p)::GetStopDescription() => error: process is running", exe_ctx.GetThreadPtr());
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
if (dst)
*dst = 0;
return 0;
}
Add the ability to capture the return value in a thread's stop info, and 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
2011-12-17 09:35:57 +08:00
SBValue
SBThread::GetStopReturnValue ()
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Add the ability to capture the return value in a thread's stop info, and 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
2011-12-17 09:35:57 +08:00
ValueObjectSP return_valobj_sp;
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Add the ability to capture the return value in a thread's stop info, and 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
2011-12-17 09:35:57 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
Add the ability to capture the return value in a thread's stop info, and 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
2011-12-17 09:35:57 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
StopInfoSP stop_info_sp = exe_ctx.GetThreadPtr()->GetStopInfo ();
if (stop_info_sp)
{
return_valobj_sp = StopInfo::GetReturnValueObject (stop_info_sp);
}
Add the ability to capture the return value in a thread's stop info, and 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
2011-12-17 09:35:57 +08:00
}
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
else
{
if (log)
log->Printf ("SBThread(%p)::GetStopReturnValue() => error: process is running", exe_ctx.GetThreadPtr());
}
Add the ability to capture the return value in a thread's stop info, and 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
2011-12-17 09:35:57 +08:00
}
if (log)
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
log->Printf ("SBThread(%p)::GetStopReturnValue () => %s", exe_ctx.GetThreadPtr(),
Add the ability to capture the return value in a thread's stop info, and 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
2011-12-17 09:35:57 +08:00
return_valobj_sp.get()
? return_valobj_sp->GetValueAsCString()
: "<no return value>");
return SBValue (return_valobj_sp);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
SBThread::SetThread (const ThreadSP& lldb_object_sp)
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
m_opaque_sp->SetThreadSP (lldb_object_sp);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
lldb::tid_t
SBThread::GetThreadID () const
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
ThreadSP thread_sp(m_opaque_sp->GetThreadSP());
Removed the "lldb-forward-rtti.h" header file as it was designed to contain 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
2012-01-30 10:53:15 +08:00
if (thread_sp)
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
return thread_sp->GetID();
return LLDB_INVALID_THREAD_ID;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
uint32_t
SBThread::GetIndexID () const
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
ThreadSP thread_sp(m_opaque_sp->GetThreadSP());
Removed the "lldb-forward-rtti.h" header file as it was designed to contain 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
2012-01-30 10:53:15 +08:00
if (thread_sp)
return thread_sp->GetIndexID();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return LLDB_INVALID_INDEX32;
}
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const char *
SBThread::GetName () const
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
const char *name = NULL;
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
{
name = exe_ctx.GetThreadPtr()->GetName();
}
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
else
{
if (log)
log->Printf ("SBThread(%p)::GetName() => error: process is running", exe_ctx.GetThreadPtr());
}
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
log->Printf ("SBThread(%p)::GetName () => %s", exe_ctx.GetThreadPtr(), name ? name : "NULL");
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
return name;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
const char *
SBThread::GetQueueName () const
{
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
const char *name = NULL;
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
{
name = exe_ctx.GetThreadPtr()->GetQueueName();
}
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
else
{
if (log)
log->Printf ("SBThread(%p)::GetQueueName() => error: process is running", exe_ctx.GetThreadPtr());
}
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
log->Printf ("SBThread(%p)::GetQueueName () => %s", exe_ctx.GetThreadPtr(), name ? name : "NULL");
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
return name;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Expose the Thread::GetQueueID() method through the SBThread API, similar to the existing SBThread::GetQueueName() method. llvm-svn: 193132
2013-10-22 07:52:54 +08:00
lldb::queue_id_t
SBThread::GetQueueID () const
{
queue_id_t id = LLDB_INVALID_QUEUE_ID;
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
if (exe_ctx.HasThreadScope())
{
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
{
id = exe_ctx.GetThreadPtr()->GetQueueID();
}
else
{
if (log)
log->Printf ("SBThread(%p)::GetQueueID() => error: process is running", exe_ctx.GetThreadPtr());
}
}
if (log)
log->Printf ("SBThread(%p)::GetQueueID () => 0x%" PRIx64, exe_ctx.GetThreadPtr(), id);
return id;
}
Clean up the usage of "MasterPlan" status in ThreadPlans. Only 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
2012-05-04 05:19:36 +08:00
SBError
SBThread::ResumeNewPlan (ExecutionContext &exe_ctx, ThreadPlan *new_plan)
{
SBError sb_error;
Process *process = exe_ctx.GetProcessPtr();
if (!process)
{
sb_error.SetErrorString("No process in SBThread::ResumeNewPlan");
return sb_error;
}
Thread *thread = exe_ctx.GetThreadPtr();
if (!thread)
{
sb_error.SetErrorString("No thread in SBThread::ResumeNewPlan");
return sb_error;
}
// User level plans should be Master Plans so they can be interrupted, other plans executed, and
// then a "continue" will resume the plan.
if (new_plan != NULL)
{
new_plan->SetIsMasterPlan(true);
new_plan->SetOkayToDiscard(false);
}
// Why do we need to set the current thread by ID here???
process->GetThreadList().SetSelectedThreadByID (thread->GetID());
sb_error.ref() = process->Resume();
if (sb_error.Success())
{
// If we are doing synchronous mode, then wait for the
// process to stop yet again!
if (process->GetTarget().GetDebugger().GetAsyncExecution () == false)
process->WaitForProcessToStop (NULL);
}
return sb_error;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
SBThread::StepOver (lldb::RunMode stop_other_threads)
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Removed the "lldb-forward-rtti.h" header file as it was designed to contain 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
2012-01-30 10:53:15 +08:00
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
log->Printf ("SBThread(%p)::StepOver (stop_other_threads='%s')", exe_ctx.GetThreadPtr(),
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Thread::RunModeAsCString (stop_other_threads));
Removed the "lldb-forward-rtti.h" header file as it was designed to contain 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
2012-01-30 10:53:15 +08:00
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
Thread *thread = exe_ctx.GetThreadPtr();
Found one more place where the OkayToDiscard needs to be consulted. 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
2012-05-12 07:47:32 +08:00
bool abort_other_plans = false;
Roll back the changes I made in r193907 which created a new Frame 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
2013-11-04 17:33:30 +08:00
StackFrameSP frame_sp(thread->GetStackFrameAtIndex (0));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
ThreadPlanSP new_plan_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (frame_sp)
{
if (frame_sp->HasDebugInformation ())
{
This commit reworks how the thread plan's ShouldStopHere mechanism works, so 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
2014-03-13 10:47:14 +08:00
const LazyBool avoid_no_debug = eLazyBoolCalculate;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SymbolContext sc(frame_sp->GetSymbolContext(eSymbolContextEverything));
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
new_plan_sp = thread->QueueThreadPlanForStepOverRange (abort_other_plans,
Fixed a few bugs in the "step in" thread plan logic. 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
2012-12-13 03:58:40 +08:00
sc.line_entry.range,
sc,
This commit reworks how the thread plan's ShouldStopHere mechanism works, so 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
2014-03-13 10:47:14 +08:00
stop_other_threads,
avoid_no_debug);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
else
{
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
new_plan_sp = thread->QueueThreadPlanForStepSingleInstruction (true,
Clean up the usage of "MasterPlan" status in ThreadPlans. Only 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
2012-05-04 05:19:36 +08:00
abort_other_plans,
stop_other_threads);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
Clean up the usage of "MasterPlan" status in ThreadPlans. Only 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
2012-05-04 05:19:36 +08:00
// This returns an error, we should use it!
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
ResumeNewPlan (exe_ctx, new_plan_sp.get());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
void
SBThread::StepInto (lldb::RunMode stop_other_threads)
Fixed a few bugs in the "step in" thread plan logic. 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
2012-12-13 03:58:40 +08:00
{
StepInto (NULL, stop_other_threads);
}
void
SBThread::StepInto (const char *target_name, lldb::RunMode stop_other_threads)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Removed the "lldb-forward-rtti.h" header file as it was designed to contain 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
2012-01-30 10:53:15 +08:00
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
Fixed a few bugs in the "step in" thread plan logic. 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
2012-12-13 03:58:40 +08:00
log->Printf ("SBThread(%p)::StepInto (target_name='%s', stop_other_threads='%s')",
exe_ctx.GetThreadPtr(),
target_name? target_name: "<NULL>",
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Thread::RunModeAsCString (stop_other_threads));
Fixed a few bugs in the "step in" thread plan logic. 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
2012-12-13 03:58:40 +08:00
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Found one more place where the OkayToDiscard needs to be consulted. 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
2012-05-12 07:47:32 +08:00
bool abort_other_plans = false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
Thread *thread = exe_ctx.GetThreadPtr();
Roll back the changes I made in r193907 which created a new Frame 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
2013-11-04 17:33:30 +08:00
StackFrameSP frame_sp(thread->GetStackFrameAtIndex (0));
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
ThreadPlanSP new_plan_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (frame_sp && frame_sp->HasDebugInformation ())
{
This commit reworks how the thread plan's ShouldStopHere mechanism works, so 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
2014-03-13 10:47:14 +08:00
const LazyBool step_out_avoids_code_without_debug_info = eLazyBoolCalculate;
const LazyBool step_in_avoids_code_without_debug_info = eLazyBoolCalculate;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SymbolContext sc(frame_sp->GetSymbolContext(eSymbolContextEverything));
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
new_plan_sp = thread->QueueThreadPlanForStepInRange (abort_other_plans,
Fixed a few bugs in the "step in" thread plan logic. 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
2012-12-13 03:58:40 +08:00
sc.line_entry.range,
sc,
target_name,
stop_other_threads,
This commit reworks how the thread plan's ShouldStopHere mechanism works, so 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
2014-03-13 10:47:14 +08:00
step_in_avoids_code_without_debug_info,
step_out_avoids_code_without_debug_info);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
else
{
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
new_plan_sp = thread->QueueThreadPlanForStepSingleInstruction (false,
Clean up the usage of "MasterPlan" status in ThreadPlans. Only 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
2012-05-04 05:19:36 +08:00
abort_other_plans,
stop_other_threads);
Added the first of hopefully many python example scripts that show how to use the python API that is exposed through SWIG to do some cool stuff. Also fixed synchronous debugging so that all process control APIs exposed through the python API will now wait for the process to stop if you set the async mode to false (see disasm.py). llvm-svn: 115738
2010-10-06 11:53:16 +08:00
}
Clean up the usage of "MasterPlan" status in ThreadPlans. Only 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
2012-05-04 05:19:36 +08:00
// This returns an error, we should use it!
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
ResumeNewPlan (exe_ctx, new_plan_sp.get());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
void
SBThread::StepOut ()
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Removed the "lldb-forward-rtti.h" header file as it was designed to contain 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
2012-01-30 10:53:15 +08:00
if (log)
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
log->Printf ("SBThread(%p)::StepOut ()", exe_ctx.GetThreadPtr());
Removed the "lldb-forward-rtti.h" header file as it was designed to contain 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
2012-01-30 10:53:15 +08:00
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Found one more place where the OkayToDiscard needs to be consulted. 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
2012-05-12 07:47:32 +08:00
bool abort_other_plans = false;
SBThread::StepOut and SBThread::StepOutOfFrame should both run all threads. llvm-svn: 163938
2012-09-15 05:07:14 +08:00
bool stop_other_threads = false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
Thread *thread = exe_ctx.GetThreadPtr();
This commit reworks how the thread plan's ShouldStopHere mechanism works, so 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
2014-03-13 10:47:14 +08:00
const LazyBool avoid_no_debug = eLazyBoolCalculate;
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
ThreadPlanSP new_plan_sp(thread->QueueThreadPlanForStepOut (abort_other_plans,
Clean up the usage of "MasterPlan" status in ThreadPlans. Only 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
2012-05-04 05:19:36 +08:00
NULL,
false,
stop_other_threads,
eVoteYes,
eVoteNoOpinion,
This commit reworks how the thread plan's ShouldStopHere mechanism works, so 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
2014-03-13 10:47:14 +08:00
0,
avoid_no_debug));
Clean up the usage of "MasterPlan" status in ThreadPlans. Only 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
2012-05-04 05:19:36 +08:00
// This returns an error, we should use it!
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
ResumeNewPlan (exe_ctx, new_plan_sp.get());
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
}
}
void
SBThread::StepOutOfFrame (lldb::SBFrame &sb_frame)
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Roll back the changes I made in r193907 which created a new Frame 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
2013-11-04 17:33:30 +08:00
StackFrameSP frame_sp (sb_frame.GetFrameSP());
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
if (log)
{
SBStream frame_desc_strm;
sb_frame.GetDescription (frame_desc_strm);
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
log->Printf ("SBThread(%p)::StepOutOfFrame (frame = SBFrame(%p): %s)", exe_ctx.GetThreadPtr(), frame_sp.get(), frame_desc_strm.GetData());
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
}
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
{
Found one more place where the OkayToDiscard needs to be consulted. 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
2012-05-12 07:47:32 +08:00
bool abort_other_plans = false;
SBThread::StepOut and SBThread::StepOutOfFrame should both run all threads. llvm-svn: 163938
2012-09-15 05:07:14 +08:00
bool stop_other_threads = false;
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
Thread *thread = exe_ctx.GetThreadPtr();
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
ThreadPlanSP new_plan_sp(thread->QueueThreadPlanForStepOut (abort_other_plans,
Clean up the usage of "MasterPlan" status in ThreadPlans. Only 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
2012-05-04 05:19:36 +08:00
NULL,
false,
stop_other_threads,
eVoteYes,
eVoteNoOpinion,
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
frame_sp->GetFrameIndex()));
Clean up the usage of "MasterPlan" status in ThreadPlans. Only 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
2012-05-04 05:19:36 +08:00
// This returns an error, we should use it!
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
ResumeNewPlan (exe_ctx, new_plan_sp.get());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
void
SBThread::StepInstruction (bool step_over)
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Removed the "lldb-forward-rtti.h" header file as it was designed to contain 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
2012-01-30 10:53:15 +08:00
if (log)
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
log->Printf ("SBThread(%p)::StepInstruction (step_over=%i)", exe_ctx.GetThreadPtr(), step_over);
Removed the "lldb-forward-rtti.h" header file as it was designed to contain 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
2012-01-30 10:53:15 +08:00
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
Thread *thread = exe_ctx.GetThreadPtr();
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
ThreadPlanSP new_plan_sp(thread->QueueThreadPlanForStepSingleInstruction (step_over, true, true));
Clean up the usage of "MasterPlan" status in ThreadPlans. Only 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
2012-05-04 05:19:36 +08:00
// This returns an error, we should use it!
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
ResumeNewPlan (exe_ctx, new_plan_sp.get());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
void
SBThread::RunToAddress (lldb::addr_t addr)
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Removed the "lldb-forward-rtti.h" header file as it was designed to contain 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
2012-01-30 10:53:15 +08:00
if (log)
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
log->Printf ("SBThread(%p)::RunToAddress (addr=0x%" PRIx64 ")", exe_ctx.GetThreadPtr(), addr);
Removed the "lldb-forward-rtti.h" header file as it was designed to contain 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
2012-01-30 10:53:15 +08:00
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Found one more place where the OkayToDiscard needs to be consulted. 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
2012-05-12 07:47:32 +08:00
bool abort_other_plans = false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool stop_other_threads = true;
<rdar://problem/10103468> 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
2012-02-24 09:59:29 +08:00
Address target_addr (addr);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
Thread *thread = exe_ctx.GetThreadPtr();
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
ThreadPlanSP new_plan_sp(thread->QueueThreadPlanForRunToAddress (abort_other_plans, target_addr, stop_other_threads));
Clean up the usage of "MasterPlan" status in ThreadPlans. Only 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
2012-05-04 05:19:36 +08:00
// This returns an error, we should use it!
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
ResumeNewPlan (exe_ctx, new_plan_sp.get());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
}
SBError
SBThread::StepOverUntil (lldb::SBFrame &sb_frame,
lldb::SBFileSpec &sb_file_spec,
uint32_t line)
{
SBError sb_error;
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
char path[PATH_MAX];
Removed the "lldb-forward-rtti.h" header file as it was designed to contain 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
2012-01-30 10:53:15 +08:00
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Roll back the changes I made in r193907 which created a new Frame 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
2013-11-04 17:33:30 +08:00
StackFrameSP frame_sp (sb_frame.GetFrameSP());
SBFrame is now threadsafe using some extra tricks. One issue is that stack 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
2012-01-30 15:41:31 +08:00
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
if (log)
{
SBStream frame_desc_strm;
sb_frame.GetDescription (frame_desc_strm);
sb_file_spec->GetPath (path, sizeof(path));
log->Printf ("SBThread(%p)::StepOverUntil (frame = SBFrame(%p): %s, file+line = %s:%u)",
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
exe_ctx.GetThreadPtr(),
SBFrame is now threadsafe using some extra tricks. One issue is that stack 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
2012-01-30 15:41:31 +08:00
frame_sp.get(),
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
frame_desc_strm.GetData(),
path, line);
}
Removed the "lldb-forward-rtti.h" header file as it was designed to contain 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
2012-01-30 10:53:15 +08:00
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
{
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
Target *target = exe_ctx.GetTargetPtr();
Thread *thread = exe_ctx.GetThreadPtr();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
if (line == 0)
{
sb_error.SetErrorString("invalid line argument");
return sb_error;
}
SBFrame is now threadsafe using some extra tricks. One issue is that stack 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
2012-01-30 15:41:31 +08:00
if (!frame_sp)
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
{
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
frame_sp = thread->GetSelectedFrame ();
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
if (!frame_sp)
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
frame_sp = thread->GetStackFrameAtIndex (0);
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
}
SymbolContext frame_sc;
if (!frame_sp)
{
sb_error.SetErrorString("no valid frames in thread to step");
return sb_error;
}
// If we have a frame, get its line
frame_sc = frame_sp->GetSymbolContext (eSymbolContextCompUnit |
eSymbolContextFunction |
eSymbolContextLineEntry |
eSymbolContextSymbol );
if (frame_sc.comp_unit == NULL)
{
sb_error.SetErrorStringWithFormat("frame %u doesn't have debug information", frame_sp->GetFrameIndex());
return sb_error;
}
FileSpec step_file_spec;
if (sb_file_spec.IsValid())
{
// The file spec passed in was valid, so use it
step_file_spec = sb_file_spec.ref();
}
else
{
if (frame_sc.line_entry.IsValid())
step_file_spec = frame_sc.line_entry.file;
else
{
sb_error.SetErrorString("invalid file argument or no file for frame");
return sb_error;
}
}
StepUntil should check whether the target of the step until is in the current function and if not return an error. llvm-svn: 131061
2011-05-08 08:56:32 +08:00
// Grab the current function, then we will make sure the "until" address is
// within the function. We discard addresses that are out of the current
// function, and then if there are no addresses remaining, give an appropriate
// error message.
bool all_in_function = true;
AddressRange fun_range = frame_sc.function->GetAddressRange();
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
std::vector<addr_t> step_over_until_addrs;
Found one more place where the OkayToDiscard needs to be consulted. 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
2012-05-12 07:47:32 +08:00
const bool abort_other_plans = false;
SBThread::StepOverUntil should run all threads. It is running to breakpoints, so running one thread is likely to cause the target to stall. llvm-svn: 163924
2012-09-15 02:57:14 +08:00
const bool stop_other_threads = false;
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
const bool check_inlines = true;
const bool exact = false;
SymbolContextList sc_list;
StepUntil should check whether the target of the step until is in the current function and if not return an error. llvm-svn: 131061
2011-05-08 08:56:32 +08:00
const uint32_t num_matches = frame_sc.comp_unit->ResolveSymbolContext (step_file_spec,
line,
check_inlines,
exact,
eSymbolContextLineEntry,
sc_list);
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
if (num_matches > 0)
{
SymbolContext sc;
for (uint32_t i=0; i<num_matches; ++i)
{
if (sc_list.GetContextAtIndex(i, sc))
{
StepUntil should check whether the target of the step until is in the current function and if not return an error. llvm-svn: 131061
2011-05-08 08:56:32 +08:00
addr_t step_addr = sc.line_entry.range.GetBaseAddress().GetLoadAddress(target);
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
if (step_addr != LLDB_INVALID_ADDRESS)
{
StepUntil should check whether the target of the step until is in the current function and if not return an error. llvm-svn: 131061
2011-05-08 08:56:32 +08:00
if (fun_range.ContainsLoadAddress(step_addr, target))
step_over_until_addrs.push_back(step_addr);
else
all_in_function = false;
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
}
}
}
}
StepUntil should check whether the target of the step until is in the current function and if not return an error. llvm-svn: 131061
2011-05-08 08:56:32 +08:00
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
if (step_over_until_addrs.empty())
{
StepUntil should check whether the target of the step until is in the current function and if not return an error. llvm-svn: 131061
2011-05-08 08:56:32 +08:00
if (all_in_function)
{
step_file_spec.GetPath (path, sizeof(path));
Update declarations for all functions/methods that accept printf-style stdarg formats to use __attribute__ format so the compiler can flag incorrect uses. Fix all incorrect uses. Most of these are innocuous, a few were resulting in crashes. llvm-svn: 140185
2011-09-21 05:44:10 +08:00
sb_error.SetErrorStringWithFormat("No line entries for %s:%u", path, line);
StepUntil should check whether the target of the step until is in the current function and if not return an error. llvm-svn: 131061
2011-05-08 08:56:32 +08:00
}
else
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
sb_error.SetErrorString ("step until target not in current function");
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
}
else
{
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
ThreadPlanSP new_plan_sp(thread->QueueThreadPlanForStepUntil (abort_other_plans,
Clean up the usage of "MasterPlan" status in ThreadPlans. Only 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
2012-05-04 05:19:36 +08:00
&step_over_until_addrs[0],
step_over_until_addrs.size(),
stop_other_threads,
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
frame_sp->GetFrameIndex()));
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
This commit does two things. One, it converts the return value of the 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
2013-07-19 05:48:26 +08:00
sb_error = ResumeNewPlan (exe_ctx, new_plan_sp.get());
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
}
}
else
{
sb_error.SetErrorString("this SBThread object is invalid");
}
return sb_error;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added a 'jump' command, similar to GDBs. 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
2013-09-12 10:20:34 +08:00
SBError
SBThread::JumpToLine (lldb::SBFileSpec &file_spec, uint32_t line)
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
SBError sb_error;
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
if (log)
log->Printf ("SBThread(%p)::JumpToLine (file+line = %s:%u)", exe_ctx.GetThreadPtr(), file_spec->GetPath().c_str(), line);
if (!exe_ctx.HasThreadScope())
{
sb_error.SetErrorString("this SBThread object is invalid");
return sb_error;
}
Thread *thread = exe_ctx.GetThreadPtr();
Error err = thread->JumpToLine (file_spec.get(), line, true);
sb_error.SetError (err);
return sb_error;
}
Start at getting "thread return" working. Doesn't work yet. llvm-svn: 163670
2012-09-12 08:40:39 +08:00
SBError
Make the unwinding of the stack part of "thread return" work, and add the thread return command. llvm-svn: 163867
2012-09-14 10:14:15 +08:00
SBThread::ReturnFromFrame (SBFrame &frame, SBValue &return_value)
Start at getting "thread return" working. Doesn't work yet. llvm-svn: 163670
2012-09-12 08:40:39 +08:00
{
SBError sb_error;
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Start at getting "thread return" working. Doesn't work yet. llvm-svn: 163670
2012-09-12 08:40:39 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
if (log)
Make the unwinding of the stack part of "thread return" work, and add the thread return command. llvm-svn: 163867
2012-09-14 10:14:15 +08:00
log->Printf ("SBThread(%p)::ReturnFromFrame (frame=%d)", exe_ctx.GetThreadPtr(), frame.GetFrameID());
Start at getting "thread return" working. Doesn't work yet. llvm-svn: 163670
2012-09-12 08:40:39 +08:00
if (exe_ctx.HasThreadScope())
{
Thread *thread = exe_ctx.GetThreadPtr();
Make the unwinding of the stack part of "thread return" work, and add the thread return command. llvm-svn: 163867
2012-09-14 10:14:15 +08:00
sb_error.SetError (thread->ReturnFromFrame(frame.GetFrameSP(), return_value.GetSP()));
Start at getting "thread return" working. Doesn't work yet. llvm-svn: 163670
2012-09-12 08:40:39 +08:00
}
return sb_error;
}
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
Added the following functions to SBThread to allow threads to be suspended when a process is resumed: bool SBThread::Suspend(); bool SBThread::Resume(); bool SBThread::IsSuspended(); llvm-svn: 123300
2011-01-12 10:25:42 +08:00
bool
SBThread::Suspend()
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
ExecutionContext exe_ctx (m_opaque_sp.get());
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
bool result = false;
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Added the following functions to SBThread to allow threads to be suspended when a process is resumed: bool SBThread::Suspend(); bool SBThread::Resume(); bool SBThread::IsSuspended(); llvm-svn: 123300
2011-01-12 10:25:42 +08:00
{
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
{
exe_ctx.GetThreadPtr()->SetResumeState (eStateSuspended);
result = true;
}
else
{
if (log)
log->Printf ("SBThread(%p)::Suspend() => error: process is running", exe_ctx.GetThreadPtr());
}
Added the following functions to SBThread to allow threads to be suspended when a process is resumed: bool SBThread::Suspend(); bool SBThread::Resume(); bool SBThread::IsSuspended(); llvm-svn: 123300
2011-01-12 10:25:42 +08:00
}
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
if (log)
log->Printf ("SBThread(%p)::Suspend() => %i", exe_ctx.GetThreadPtr(), result);
return result;
Added the following functions to SBThread to allow threads to be suspended when a process is resumed: bool SBThread::Suspend(); bool SBThread::Resume(); bool SBThread::IsSuspended(); llvm-svn: 123300
2011-01-12 10:25:42 +08:00
}
bool
SBThread::Resume ()
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
ExecutionContext exe_ctx (m_opaque_sp.get());
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
bool result = false;
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Added the following functions to SBThread to allow threads to be suspended when a process is resumed: bool SBThread::Suspend(); bool SBThread::Resume(); bool SBThread::IsSuspended(); llvm-svn: 123300
2011-01-12 10:25:42 +08:00
{
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
{
Make the fail messages llvm-svn: 205497
2014-04-03 09:26:14 +08:00
const bool override_suspend = true;
exe_ctx.GetThreadPtr()->SetResumeState (eStateRunning, override_suspend);
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
result = true;
}
else
{
if (log)
log->Printf ("SBThread(%p)::Resume() => error: process is running", exe_ctx.GetThreadPtr());
}
Added the following functions to SBThread to allow threads to be suspended when a process is resumed: bool SBThread::Suspend(); bool SBThread::Resume(); bool SBThread::IsSuspended(); llvm-svn: 123300
2011-01-12 10:25:42 +08:00
}
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
if (log)
log->Printf ("SBThread(%p)::Resume() => %i", exe_ctx.GetThreadPtr(), result);
return result;
Added the following functions to SBThread to allow threads to be suspended when a process is resumed: bool SBThread::Suspend(); bool SBThread::Resume(); bool SBThread::IsSuspended(); llvm-svn: 123300
2011-01-12 10:25:42 +08:00
}
bool
SBThread::IsSuspended()
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
ExecutionContext exe_ctx (m_opaque_sp.get());
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
return exe_ctx.GetThreadPtr()->GetResumeState () == eStateSuspended;
Added the following functions to SBThread to allow threads to be suspended when a process is resumed: bool SBThread::Suspend(); bool SBThread::Resume(); bool SBThread::IsSuspended(); llvm-svn: 123300
2011-01-12 10:25:42 +08:00
return false;
}
Adding new Python API function to check for stopped threads. llvm-svn: 179577
2013-04-16 07:33:53 +08:00
bool
SBThread::IsStopped()
{
ExecutionContext exe_ctx (m_opaque_sp.get());
if (exe_ctx.HasThreadScope())
return StateIsStoppedState(exe_ctx.GetThreadPtr()->GetState(), true);
return false;
}
Added the following functions to SBThread to allow threads to be suspended when a process is resumed: bool SBThread::Suspend(); bool SBThread::Resume(); bool SBThread::IsSuspended(); llvm-svn: 123300
2011-01-12 10:25:42 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBProcess
SBThread::GetProcess ()
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack 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
2012-01-30 15:41:31 +08:00
SBProcess sb_process;
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
ExecutionContext exe_ctx (m_opaque_sp.get());
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
// Have to go up to the target so we can get a shared pointer to our process...
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
sb_process.SetSP (exe_ctx.GetProcessSP());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
{
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
SBStream frame_desc_strm;
SBFrame is now threadsafe using some extra tricks. One issue is that stack 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
2012-01-30 15:41:31 +08:00
sb_process.GetDescription (frame_desc_strm);
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
log->Printf ("SBThread(%p)::GetProcess () => SBProcess(%p): %s", exe_ctx.GetThreadPtr(),
the log entry for SBThread::GetProcess() would not include the pointer to 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
2013-02-28 10:18:49 +08:00
sb_process.GetSP().get(), frame_desc_strm.GetData());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
}
SBFrame is now threadsafe using some extra tricks. One issue is that stack 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
2012-01-30 15:41:31 +08:00
return sb_process;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
uint32_t
SBThread::GetNumFrames ()
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
uint32_t num_frames = 0;
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
{
num_frames = exe_ctx.GetThreadPtr()->GetStackFrameCount();
}
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
else
{
if (log)
log->Printf ("SBThread(%p)::GetNumFrames() => error: process is running", exe_ctx.GetThreadPtr());
}
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
log->Printf ("SBThread(%p)::GetNumFrames () => %u", exe_ctx.GetThreadPtr(), num_frames);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
return num_frames;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
SBFrame
SBThread::GetFrameAtIndex (uint32_t idx)
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBFrame sb_frame;
Roll back the changes I made in r193907 which created a new Frame 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
2013-11-04 17:33:30 +08:00
StackFrameSP frame_sp;
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
{
frame_sp = exe_ctx.GetThreadPtr()->GetStackFrameAtIndex (idx);
sb_frame.SetFrameSP (frame_sp);
}
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
else
{
if (log)
log->Printf ("SBThread(%p)::GetFrameAtIndex() => error: process is running", exe_ctx.GetThreadPtr());
}
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
{
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
SBStream frame_desc_strm;
sb_frame.GetDescription (frame_desc_strm);
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
log->Printf ("SBThread(%p)::GetFrameAtIndex (idx=%d) => SBFrame(%p): %s",
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
exe_ctx.GetThreadPtr(), idx, frame_sp.get(), frame_desc_strm.GetData());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_frame;
}
Added access to set the current stack frame within a thread so any command line commands can use the current thread/frame. Fixed an issue with expressions that get sandboxed in an objective C method where unichar wasn't being passed down. Added a "static size_t Scalar::GetMaxByteSize();" function in case we need to know the max supported by size of something within a Scalar object. llvm-svn: 122027
2010-12-17 10:26:24 +08:00
lldb::SBFrame
SBThread::GetSelectedFrame ()
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Added access to set the current stack frame within a thread so any command line commands can use the current thread/frame. Fixed an issue with expressions that get sandboxed in an objective C method where unichar wasn't being passed down. Added a "static size_t Scalar::GetMaxByteSize();" function in case we need to know the max supported by size of something within a Scalar object. llvm-svn: 122027
2010-12-17 10:26:24 +08:00
SBFrame sb_frame;
Roll back the changes I made in r193907 which created a new Frame 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
2013-11-04 17:33:30 +08:00
StackFrameSP frame_sp;
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
{
frame_sp = exe_ctx.GetThreadPtr()->GetSelectedFrame ();
sb_frame.SetFrameSP (frame_sp);
}
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
else
{
if (log)
log->Printf ("SBThread(%p)::GetSelectedFrame() => error: process is running", exe_ctx.GetThreadPtr());
}
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Added access to set the current stack frame within a thread so any command line commands can use the current thread/frame. Fixed an issue with expressions that get sandboxed in an objective C method where unichar wasn't being passed down. Added a "static size_t Scalar::GetMaxByteSize();" function in case we need to know the max supported by size of something within a Scalar object. llvm-svn: 122027
2010-12-17 10:26:24 +08:00
if (log)
{
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
SBStream frame_desc_strm;
sb_frame.GetDescription (frame_desc_strm);
Added access to set the current stack frame within a thread so any command line commands can use the current thread/frame. Fixed an issue with expressions that get sandboxed in an objective C method where unichar wasn't being passed down. Added a "static size_t Scalar::GetMaxByteSize();" function in case we need to know the max supported by size of something within a Scalar object. llvm-svn: 122027
2010-12-17 10:26:24 +08:00
log->Printf ("SBThread(%p)::GetSelectedFrame () => SBFrame(%p): %s",
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
exe_ctx.GetThreadPtr(), frame_sp.get(), frame_desc_strm.GetData());
Added access to set the current stack frame within a thread so any command line commands can use the current thread/frame. Fixed an issue with expressions that get sandboxed in an objective C method where unichar wasn't being passed down. Added a "static size_t Scalar::GetMaxByteSize();" function in case we need to know the max supported by size of something within a Scalar object. llvm-svn: 122027
2010-12-17 10:26:24 +08:00
}
return sb_frame;
}
lldb::SBFrame
SBThread::SetSelectedFrame (uint32_t idx)
{
<rdar://problem/13521159> 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
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Added access to set the current stack frame within a thread so any command line commands can use the current thread/frame. Fixed an issue with expressions that get sandboxed in an objective C method where unichar wasn't being passed down. Added a "static size_t Scalar::GetMaxByteSize();" function in case we need to know the max supported by size of something within a Scalar object. llvm-svn: 122027
2010-12-17 10:26:24 +08:00
SBFrame sb_frame;
Roll back the changes I made in r193907 which created a new Frame 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
2013-11-04 17:33:30 +08:00
StackFrameSP frame_sp;
Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-23 05:34:33 +08:00
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
Added access to set the current stack frame within a thread so any command line commands can use the current thread/frame. Fixed an issue with expressions that get sandboxed in an objective C method where unichar wasn't being passed down. Added a "static size_t Scalar::GetMaxByteSize();" function in case we need to know the max supported by size of something within a Scalar object. llvm-svn: 122027
2010-12-17 10:26:24 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
Added access to set the current stack frame within a thread so any command line commands can use the current thread/frame. Fixed an issue with expressions that get sandboxed in an objective C method where unichar wasn't being passed down. Added a "static size_t Scalar::GetMaxByteSize();" function in case we need to know the max supported by size of something within a Scalar object. llvm-svn: 122027
2010-12-17 10:26:24 +08:00
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
Thread *thread = exe_ctx.GetThreadPtr();
frame_sp = thread->GetStackFrameAtIndex (idx);
if (frame_sp)
{
thread->SetSelectedFrame (frame_sp.get());
sb_frame.SetFrameSP (frame_sp);
}
Added access to set the current stack frame within a thread so any command line commands can use the current thread/frame. Fixed an issue with expressions that get sandboxed in an objective C method where unichar wasn't being passed down. Added a "static size_t Scalar::GetMaxByteSize();" function in case we need to know the max supported by size of something within a Scalar object. llvm-svn: 122027
2010-12-17 10:26:24 +08:00
}
Added logging when API calls try to do something that shouldn't be done when 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
2012-04-06 10:17:47 +08:00
else
{
if (log)
log->Printf ("SBThread(%p)::SetSelectedFrame() => error: process is running", exe_ctx.GetThreadPtr());
}
Added access to set the current stack frame within a thread so any command line commands can use the current thread/frame. Fixed an issue with expressions that get sandboxed in an objective C method where unichar wasn't being passed down. Added a "static size_t Scalar::GetMaxByteSize();" function in case we need to know the max supported by size of something within a Scalar object. llvm-svn: 122027
2010-12-17 10:26:24 +08:00
}
if (log)
{
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
SBStream frame_desc_strm;
sb_frame.GetDescription (frame_desc_strm);
Added access to set the current stack frame within a thread so any command line commands can use the current thread/frame. Fixed an issue with expressions that get sandboxed in an objective C method where unichar wasn't being passed down. Added a "static size_t Scalar::GetMaxByteSize();" function in case we need to know the max supported by size of something within a Scalar object. llvm-svn: 122027
2010-12-17 10:26:24 +08:00
log->Printf ("SBThread(%p)::SetSelectedFrame (idx=%u) => SBFrame(%p): %s",
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
exe_ctx.GetThreadPtr(), idx, frame_sp.get(), frame_desc_strm.GetData());
Added access to set the current stack frame within a thread so any command line commands can use the current thread/frame. Fixed an issue with expressions that get sandboxed in an objective C method where unichar wasn't being passed down. Added a "static size_t Scalar::GetMaxByteSize();" function in case we need to know the max supported by size of something within a Scalar object. llvm-svn: 122027
2010-12-17 10:26:24 +08:00
}
return sb_frame;
}
Change the Thread constructor over to take a Process& rather than a 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
2012-10-11 02:32:14 +08:00
bool
SBThread::EventIsThreadEvent (const SBEvent &event)
{
return Thread::ThreadEventData::GetEventDataFromEvent(event.get()) != NULL;
}
SBFrame
SBThread::GetStackFrameFromEvent (const SBEvent &event)
{
return Thread::ThreadEventData::GetStackFrameFromEvent (event.get());
}
SBThread
SBThread::GetThreadFromEvent (const SBEvent &event)
{
return Thread::ThreadEventData::GetThreadFromEvent (event.get());
}
Added access to set the current stack frame within a thread so any command line commands can use the current thread/frame. Fixed an issue with expressions that get sandboxed in an objective C method where unichar wasn't being passed down. Added a "static size_t Scalar::GetMaxByteSize();" function in case we need to know the max supported by size of something within a Scalar object. llvm-svn: 122027
2010-12-17 10:26:24 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool
SBThread::operator == (const SBThread &rhs) const
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
return m_opaque_sp->GetThreadSP().get() == rhs.m_opaque_sp->GetThreadSP().get();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
bool
SBThread::operator != (const SBThread &rhs) const
{
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
return m_opaque_sp->GetThreadSP().get() != rhs.m_opaque_sp->GetThreadSP().get();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
Change the Thread constructor over to take a Process& rather than a 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
2012-10-11 02:32:14 +08:00
bool
SBThread::GetStatus (SBStream &status) const
{
Stream &strm = status.ref();
ExecutionContext exe_ctx (m_opaque_sp.get());
if (exe_ctx.HasThreadScope())
{
exe_ctx.GetThreadPtr()->GetStatus(strm, 0, 1, 1);
}
else
strm.PutCString ("No status");
return true;
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
bool
SBThread::GetDescription (SBStream &description) const
{
<rdar://problem/10126482> 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
2011-11-13 14:57:31 +08:00
Stream &strm = description.ref();
Added a new Host class: ReadWriteLock 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
2012-04-06 00:12:35 +08:00
ExecutionContext exe_ctx (m_opaque_sp.get());
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr 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
2012-02-21 08:09:25 +08:00
if (exe_ctx.HasThreadScope())
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
{
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
strm.Printf("SBThread: tid = 0x%4.4" PRIx64, exe_ctx.GetThreadPtr()->GetID());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
}
else
<rdar://problem/10126482> 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
2011-11-13 14:57:31 +08:00
strm.PutCString ("No value");
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
return true;
}
Add a new GetThreadOriginExtendedBacktrace method to the SystemRuntime and SBThread classes. <rdar://problem/15314369> llvm-svn: 194111
2013-11-06 08:04:44 +08:00
SBThread
Change SBThread::GetExtendedBacktrace to SBThread::GetExtendedBacktraceThread to make it more clear what is being returned. llvm-svn: 194531
2013-11-13 07:33:32 +08:00
SBThread::GetExtendedBacktraceThread (const char *type)
Add a new GetThreadOriginExtendedBacktrace method to the SystemRuntime and SBThread classes. <rdar://problem/15314369> llvm-svn: 194111
2013-11-06 08:04:44 +08:00
{
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Mutex::Locker api_locker;
ExecutionContext exe_ctx (m_opaque_sp.get(), api_locker);
SBThread sb_origin_thread;
if (exe_ctx.HasThreadScope())
{
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&exe_ctx.GetProcessPtr()->GetRunLock()))
{
The Threads created when requesting extended backtraces need to be owned by 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
2013-11-11 13:19:34 +08:00
ThreadSP real_thread(exe_ctx.GetThreadSP());
Add a new GetThreadOriginExtendedBacktrace method to the SystemRuntime and SBThread classes. <rdar://problem/15314369> llvm-svn: 194111
2013-11-06 08:04:44 +08:00
if (real_thread)
{
ConstString type_const (type);
The Threads created when requesting extended backtraces need to be owned by 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
2013-11-11 13:19:34 +08:00
Process *process = exe_ctx.GetProcessPtr();
if (process)
Add a new GetThreadOriginExtendedBacktrace method to the SystemRuntime and SBThread classes. <rdar://problem/15314369> llvm-svn: 194111
2013-11-06 08:04:44 +08:00
{
The Threads created when requesting extended backtraces need to be owned by 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
2013-11-11 13:19:34 +08:00
SystemRuntime *runtime = process->GetSystemRuntime();
if (runtime)
{
Change SBThread::GetExtendedBacktrace to SBThread::GetExtendedBacktraceThread to make it more clear what is being returned. llvm-svn: 194531
2013-11-13 07:33:32 +08:00
ThreadSP new_thread_sp (runtime->GetExtendedBacktraceThread (real_thread, type_const));
Add logging for the SB API which creates extended threads. Take a stab at fixing the too-soon freeing of the extended backtrace thread list in Process. <rdar://problem/15496603> llvm-svn: 195104
2013-11-19 13:44:41 +08:00
if (new_thread_sp)
{
// Save this in the Process' ExtendedThreadList so a strong pointer retains the
// object.
process->GetExtendedThreadList().AddThread (new_thread_sp);
sb_origin_thread.SetThread (new_thread_sp);
if (log)
{
const char *queue_name = new_thread_sp->GetQueueName();
if (queue_name == NULL)
queue_name = "";
log->Printf ("SBThread(%p)::GetExtendedBacktraceThread() => new extended Thread created (%p) with queue_id 0x%" PRIx64 " queue name '%s'", exe_ctx.GetThreadPtr(), new_thread_sp.get(), new_thread_sp->GetQueueID(), queue_name);
}
}
The Threads created when requesting extended backtraces need to be owned by 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
2013-11-11 13:19:34 +08:00
}
Add a new GetThreadOriginExtendedBacktrace method to the SystemRuntime and SBThread classes. <rdar://problem/15314369> llvm-svn: 194111
2013-11-06 08:04:44 +08:00
}
}
}
else
{
if (log)
Add logging for the SB API which creates extended threads. Take a stab at fixing the too-soon freeing of the extended backtrace thread list in Process. <rdar://problem/15496603> llvm-svn: 195104
2013-11-19 13:44:41 +08:00
log->Printf ("SBThread(%p)::GetExtendedBacktraceThread() => error: process is running", exe_ctx.GetThreadPtr());
Add a new GetThreadOriginExtendedBacktrace method to the SystemRuntime and SBThread classes. <rdar://problem/15314369> llvm-svn: 194111
2013-11-06 08:04:44 +08:00
}
}
Add API logging to the SBQueue/SBQueueItem/SBThread calls. llvm-svn: 203330
2014-03-08 09:34:55 +08:00
if (log && sb_origin_thread.IsValid() == false)
{
log->Printf("SBThread(%p)::GetExtendedBacktraceThread() is not returning a Valid thread", exe_ctx.GetThreadPtr());
}
Add a new GetThreadOriginExtendedBacktrace method to the SystemRuntime and SBThread classes. <rdar://problem/15314369> llvm-svn: 194111
2013-11-06 08:04:44 +08:00
return sb_origin_thread;
}
Add a new SBThread::GetExtendedBacktraceOriginatingIndexID() method (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
2013-11-16 09:24:22 +08:00
uint32_t
SBThread::GetExtendedBacktraceOriginatingIndexID ()
{
ThreadSP thread_sp(m_opaque_sp->GetThreadSP());
if (thread_sp)
return thread_sp->GetExtendedBacktraceOriginatingIndexID();
return LLDB_INVALID_INDEX32;
}