replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/lldb/source/Target/ExecutionContext.cpp

840 lines
20 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
//===-- ExecutionContext.cpp ------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/Target/ExecutionContext.h"
Don't set the thread when adopting selected execution context entries, and use the "lldb_private::StateIsStoppedState(StateType, bool)" function to tell if the state is stopped. llvm-svn: 161000
2012-07-31 06:05:39 +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/Target/ExecutionContextScope.h"
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
#include "lldb/Target/StackFrame.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Target/Process.h"
#include "lldb/Target/Target.h"
#include "lldb/Target/Thread.h"
using namespace lldb_private;
ExecutionContext::ExecutionContext() :
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
m_target_sp (),
m_process_sp (),
m_thread_sp (),
m_frame_sp ()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
}
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
ExecutionContext::ExecutionContext (const ExecutionContext &rhs) :
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
m_target_sp(rhs.m_target_sp),
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
m_process_sp(rhs.m_process_sp),
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
m_thread_sp(rhs.m_thread_sp),
m_frame_sp(rhs.m_frame_sp)
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
{
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
ExecutionContext::ExecutionContext (const lldb::TargetSP &target_sp, bool get_process) :
m_target_sp (),
m_process_sp (),
m_thread_sp (),
m_frame_sp ()
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
{
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
if (target_sp)
SetContext (target_sp, get_process);
}
ExecutionContext::ExecutionContext (const lldb::ProcessSP &process_sp) :
m_target_sp (),
m_process_sp (),
m_thread_sp (),
m_frame_sp ()
{
if (process_sp)
SetContext (process_sp);
}
ExecutionContext::ExecutionContext (const lldb::ThreadSP &thread_sp) :
m_target_sp (),
m_process_sp (),
m_thread_sp (),
m_frame_sp ()
{
if (thread_sp)
SetContext (thread_sp);
}
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
ExecutionContext::ExecutionContext (const lldb::StackFrameSP &frame_sp) :
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
m_target_sp (),
m_process_sp (),
m_thread_sp (),
m_frame_sp ()
{
if (frame_sp)
SetContext (frame_sp);
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +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
ExecutionContext::ExecutionContext (const lldb::TargetWP &target_wp, bool get_process) :
m_target_sp (),
m_process_sp (),
m_thread_sp (),
m_frame_sp ()
{
lldb::TargetSP target_sp(target_wp.lock());
if (target_sp)
SetContext (target_sp, get_process);
}
ExecutionContext::ExecutionContext (const lldb::ProcessWP &process_wp) :
m_target_sp (),
m_process_sp (),
m_thread_sp (),
m_frame_sp ()
{
lldb::ProcessSP process_sp(process_wp.lock());
if (process_sp)
SetContext (process_sp);
}
ExecutionContext::ExecutionContext (const lldb::ThreadWP &thread_wp) :
m_target_sp (),
m_process_sp (),
m_thread_sp (),
m_frame_sp ()
{
lldb::ThreadSP thread_sp(thread_wp.lock());
if (thread_sp)
SetContext (thread_sp);
}
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
ExecutionContext::ExecutionContext (const lldb::StackFrameWP &frame_wp) :
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
m_target_sp (),
m_process_sp (),
m_thread_sp (),
m_frame_sp ()
{
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
lldb::StackFrameSP frame_sp(frame_wp.lock());
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 (frame_sp)
SetContext (frame_sp);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
ExecutionContext::ExecutionContext (Target* t, bool fill_current_process_thread_frame) :
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2012-01-30 04:56:30 +08:00
m_target_sp (t->shared_from_this()),
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
m_process_sp (),
m_thread_sp (),
m_frame_sp ()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
if (t && fill_current_process_thread_frame)
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
m_process_sp = t->GetProcessSP();
if (m_process_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
m_thread_sp = m_process_sp->GetThreadList().GetSelectedThread();
if (m_thread_sp)
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2012-01-30 04:56:30 +08:00
m_frame_sp = m_thread_sp->GetSelectedFrame();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
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
ExecutionContext::ExecutionContext(Process* process, Thread *thread, StackFrame *frame) :
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2012-01-30 04:56:30 +08:00
m_target_sp (),
m_process_sp (process->shared_from_this()),
m_thread_sp (thread->shared_from_this()),
m_frame_sp (frame->shared_from_this())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2012-01-30 04:56:30 +08:00
if (process)
m_target_sp = process->GetTarget().shared_from_this();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
ExecutionContext::ExecutionContext (const ExecutionContextRef &exe_ctx_ref) :
m_target_sp (exe_ctx_ref.GetTargetSP()),
m_process_sp (exe_ctx_ref.GetProcessSP()),
m_thread_sp (exe_ctx_ref.GetThreadSP()),
m_frame_sp (exe_ctx_ref.GetFrameSP())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
}
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
ExecutionContext::ExecutionContext (const ExecutionContextRef *exe_ctx_ref_ptr, bool thread_and_frame_only_if_stopped) :
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
m_target_sp (),
m_process_sp (),
m_thread_sp (),
m_frame_sp ()
{
if (exe_ctx_ref_ptr)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
m_target_sp = exe_ctx_ref_ptr->GetTargetSP();
m_process_sp = exe_ctx_ref_ptr->GetProcessSP();
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
if (!thread_and_frame_only_if_stopped || (m_process_sp && StateIsStoppedState(m_process_sp->GetState(), true)))
{
m_thread_sp = exe_ctx_ref_ptr->GetThreadSP();
m_frame_sp = exe_ctx_ref_ptr->GetFrameSP();
}
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
ExecutionContext::ExecutionContext (const ExecutionContextRef *exe_ctx_ref_ptr, Mutex::Locker &locker) :
m_target_sp (),
m_process_sp (),
m_thread_sp (),
m_frame_sp ()
{
if (exe_ctx_ref_ptr)
{
m_target_sp = exe_ctx_ref_ptr->GetTargetSP();
if (m_target_sp)
{
locker.Lock(m_target_sp->GetAPIMutex());
m_process_sp = exe_ctx_ref_ptr->GetProcessSP();
m_thread_sp = exe_ctx_ref_ptr->GetThreadSP();
m_frame_sp = exe_ctx_ref_ptr->GetFrameSP();
}
}
}
ExecutionContext::ExecutionContext (const ExecutionContextRef &exe_ctx_ref, Mutex::Locker &locker) :
m_target_sp (exe_ctx_ref.GetTargetSP()),
m_process_sp (),
m_thread_sp (),
m_frame_sp ()
{
if (m_target_sp)
{
locker.Lock(m_target_sp->GetAPIMutex());
m_process_sp = exe_ctx_ref.GetProcessSP();
m_thread_sp = exe_ctx_ref.GetThreadSP();
m_frame_sp = exe_ctx_ref.GetFrameSP();
}
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
ExecutionContext::ExecutionContext (ExecutionContextScope *exe_scope_ptr) :
m_target_sp (),
m_process_sp (),
m_thread_sp (),
m_frame_sp ()
{
if (exe_scope_ptr)
exe_scope_ptr->CalculateExecutionContext (*this);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
ExecutionContext::ExecutionContext (ExecutionContextScope &exe_scope_ref)
{
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
exe_scope_ref.CalculateExecutionContext (*this);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
void
ExecutionContext::Clear()
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
m_target_sp.reset();
m_process_sp.reset();
m_thread_sp.reset();
m_frame_sp.reset();
}
ExecutionContext::~ExecutionContext()
{
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
uint32_t
ExecutionContext::GetAddressByteSize() const
{
if (m_target_sp && m_target_sp->GetArchitecture().IsValid())
m_target_sp->GetArchitecture().GetAddressByteSize();
if (m_process_sp)
m_process_sp->GetAddressByteSize();
return sizeof(void *);
}
<rdar://problem/14028923> Implement SBTarget::CreateValueFromAddress() with a behavior equivalent to SBValue::CreateValueFromAddress() (but without the need to grab an SBValue first just as a starting point to make up another SBValue out of whole cloth) llvm-svn: 192239
2013-10-09 05:49:02 +08:00
lldb::ByteOrder
ExecutionContext::GetByteOrder() const
{
if (m_target_sp && m_target_sp->GetArchitecture().IsValid())
m_target_sp->GetArchitecture().GetByteOrder();
if (m_process_sp)
m_process_sp->GetByteOrder();
return lldb::endian::InlHostByteOrder();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
RegisterContext *
ExecutionContext::GetRegisterContext () const
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
if (m_frame_sp)
return m_frame_sp->GetRegisterContext().get();
else if (m_thread_sp)
return m_thread_sp->GetRegisterContext().get();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return NULL;
}
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
Target *
ExecutionContext::GetTargetPtr () const
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
if (m_target_sp)
return m_target_sp.get();
if (m_process_sp)
return &m_process_sp->GetTarget();
return NULL;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added "target variable" command that allows introspection of global variables prior to running your binary. Zero filled sections now get section data correctly filled with zeroes when Target::ReadMemory reads from the object file section data. Added new option groups and option values for file lists. I still need to hook up all of the options to "target variable" to allow more complete introspection by file and shlib. Added the ability for ValueObjectVariable objects to be created with only the target as the execution context. This allows them to be read from the object files through Target::ReadMemory(...). Added a "virtual Module * GetModule()" function to the ValueObject class. By default it will look to the parent variable object and return its module. The module is needed when we have global variables that have file addresses (virtual addresses that are specific to module object files) and in turn allows global variables to be displayed prior to running. Removed all of the unused proxy object support that bit rotted in lldb_private::Value. Replaced a lot of places that used "FileSpec::Compare (lhs, rhs) == 0" code with the more efficient "FileSpec::Equal (lhs, rhs)". Improved logging in GDB remote plug-in. llvm-svn: 134579
2011-07-07 09:59:51 +08:00
Process *
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
ExecutionContext::GetProcessPtr () const
Added "target variable" command that allows introspection of global variables prior to running your binary. Zero filled sections now get section data correctly filled with zeroes when Target::ReadMemory reads from the object file section data. Added new option groups and option values for file lists. I still need to hook up all of the options to "target variable" to allow more complete introspection by file and shlib. Added the ability for ValueObjectVariable objects to be created with only the target as the execution context. This allows them to be read from the object files through Target::ReadMemory(...). Added a "virtual Module * GetModule()" function to the ValueObject class. By default it will look to the parent variable object and return its module. The module is needed when we have global variables that have file addresses (virtual addresses that are specific to module object files) and in turn allows global variables to be displayed prior to running. Removed all of the unused proxy object support that bit rotted in lldb_private::Value. Replaced a lot of places that used "FileSpec::Compare (lhs, rhs) == 0" code with the more efficient "FileSpec::Equal (lhs, rhs)". Improved logging in GDB remote plug-in. llvm-svn: 134579
2011-07-07 09:59:51 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
if (m_process_sp)
return m_process_sp.get();
if (m_target_sp)
return m_target_sp->GetProcessSP().get();
Added "target variable" command that allows introspection of global variables prior to running your binary. Zero filled sections now get section data correctly filled with zeroes when Target::ReadMemory reads from the object file section data. Added new option groups and option values for file lists. I still need to hook up all of the options to "target variable" to allow more complete introspection by file and shlib. Added the ability for ValueObjectVariable objects to be created with only the target as the execution context. This allows them to be read from the object files through Target::ReadMemory(...). Added a "virtual Module * GetModule()" function to the ValueObject class. By default it will look to the parent variable object and return its module. The module is needed when we have global variables that have file addresses (virtual addresses that are specific to module object files) and in turn allows global variables to be displayed prior to running. Removed all of the unused proxy object support that bit rotted in lldb_private::Value. Replaced a lot of places that used "FileSpec::Compare (lhs, rhs) == 0" code with the more efficient "FileSpec::Equal (lhs, rhs)". Improved logging in GDB remote plug-in. llvm-svn: 134579
2011-07-07 09:59:51 +08:00
return NULL;
}
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
ExecutionContextScope *
ExecutionContext::GetBestExecutionContextScope () const
{
if (m_frame_sp)
return m_frame_sp.get();
if (m_thread_sp)
return m_thread_sp.get();
if (m_process_sp)
return m_process_sp.get();
return m_target_sp.get();
}
Target &
ExecutionContext::GetTargetRef () const
{
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 defined (LLDB_CONFIGURATION_DEBUG) || defined (LLDB_CONFIGURATION_RELEASE)
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
assert (m_target_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
#endif
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
return *m_target_sp;
}
Process &
ExecutionContext::GetProcessRef () const
{
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 defined (LLDB_CONFIGURATION_DEBUG) || defined (LLDB_CONFIGURATION_RELEASE)
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
assert (m_process_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
#endif
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
return *m_process_sp;
}
Thread &
ExecutionContext::GetThreadRef () const
{
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 defined (LLDB_CONFIGURATION_DEBUG) || defined (LLDB_CONFIGURATION_RELEASE)
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
assert (m_thread_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
#endif
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
return *m_thread_sp;
}
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
StackFrame &
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
ExecutionContext::GetFrameRef () const
{
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 defined (LLDB_CONFIGURATION_DEBUG) || defined (LLDB_CONFIGURATION_RELEASE)
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
assert (m_frame_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
#endif
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
return *m_frame_sp;
}
void
ExecutionContext::SetTargetSP (const lldb::TargetSP &target_sp)
{
m_target_sp = target_sp;
}
void
ExecutionContext::SetProcessSP (const lldb::ProcessSP &process_sp)
{
m_process_sp = process_sp;
}
void
ExecutionContext::SetThreadSP (const lldb::ThreadSP &thread_sp)
{
m_thread_sp = thread_sp;
}
void
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
ExecutionContext::SetFrameSP (const lldb::StackFrameSP &frame_sp)
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
{
m_frame_sp = frame_sp;
}
void
ExecutionContext::SetTargetPtr (Target* target)
{
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2012-01-30 04:56:30 +08:00
if (target)
m_target_sp = target->shared_from_this();
else
m_target_sp.reset();
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
}
void
ExecutionContext::SetProcessPtr (Process *process)
{
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2012-01-30 04:56:30 +08:00
if (process)
m_process_sp = process->shared_from_this();
else
m_process_sp.reset();
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
}
void
ExecutionContext::SetThreadPtr (Thread *thread)
{
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2012-01-30 04:56:30 +08:00
if (thread)
m_thread_sp = thread->shared_from_this();
else
m_thread_sp.reset();
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
}
void
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
ExecutionContext::SetFramePtr (StackFrame *frame)
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
{
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2012-01-30 04:56:30 +08:00
if (frame)
m_frame_sp = frame->shared_from_this();
else
m_frame_sp.reset();
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
void
ExecutionContext::SetContext (const lldb::TargetSP &target_sp, bool get_process)
{
m_target_sp = target_sp;
if (get_process && target_sp)
m_process_sp = target_sp->GetProcessSP();
else
m_process_sp.reset();
m_thread_sp.reset();
m_frame_sp.reset();
}
void
ExecutionContext::SetContext (const lldb::ProcessSP &process_sp)
{
m_process_sp = process_sp;
if (process_sp)
m_target_sp = process_sp->GetTarget().shared_from_this();
else
m_target_sp.reset();
m_thread_sp.reset();
m_frame_sp.reset();
}
void
ExecutionContext::SetContext (const lldb::ThreadSP &thread_sp)
{
m_frame_sp.reset();
m_thread_sp = thread_sp;
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
m_process_sp = thread_sp->GetProcess();
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
if (m_process_sp)
m_target_sp = m_process_sp->GetTarget().shared_from_this();
else
m_target_sp.reset();
}
else
{
m_target_sp.reset();
m_process_sp.reset();
}
}
void
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
ExecutionContext::SetContext (const lldb::StackFrameSP &frame_sp)
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
{
m_frame_sp = frame_sp;
if (frame_sp)
{
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
m_thread_sp = frame_sp->CalculateThread();
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
if (m_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
m_process_sp = m_thread_sp->GetProcess();
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
if (m_process_sp)
m_target_sp = m_process_sp->GetTarget().shared_from_this();
else
m_target_sp.reset();
}
else
{
m_target_sp.reset();
m_process_sp.reset();
}
}
else
{
m_target_sp.reset();
m_process_sp.reset();
m_thread_sp.reset();
}
}
ExecutionContext &
ExecutionContext::operator =(const ExecutionContext &rhs)
{
if (this != &rhs)
{
m_target_sp = rhs.m_target_sp;
m_process_sp = rhs.m_process_sp;
m_thread_sp = rhs.m_thread_sp;
m_frame_sp = rhs.m_frame_sp;
}
return *this;
}
bool
ExecutionContext::operator ==(const ExecutionContext &rhs) const
{
// Check that the frame shared pointers match, or both are valid and their stack
// IDs match since sometimes we get new objects that represent the same
// frame within a thread.
if ((m_frame_sp == rhs.m_frame_sp) || (m_frame_sp && rhs.m_frame_sp && m_frame_sp->GetStackID() == rhs.m_frame_sp->GetStackID()))
{
// Check that the thread shared pointers match, or both are valid and
// their thread IDs match since sometimes we get new objects that
// represent the same thread within a process.
if ((m_thread_sp == rhs.m_thread_sp) || (m_thread_sp && rhs.m_thread_sp && m_thread_sp->GetID() == rhs.m_thread_sp->GetID()))
{
// Processes and targets don't change much
return m_process_sp == rhs.m_process_sp && m_target_sp == rhs.m_target_sp;
}
}
return false;
}
bool
ExecutionContext::operator !=(const ExecutionContext &rhs) const
{
return !(*this == rhs);
}
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
bool
ExecutionContext::HasTargetScope () const
{
return ((bool) m_target_sp
&& m_target_sp->IsValid());
}
bool
ExecutionContext::HasProcessScope () const
{
return (HasTargetScope()
&& ((bool) m_process_sp && m_process_sp->IsValid()));
}
bool
ExecutionContext::HasThreadScope () const
{
return (HasProcessScope()
&& ((bool) m_thread_sp && m_thread_sp->IsValid()));
}
bool
ExecutionContext::HasFrameScope () const
{
return HasThreadScope() && m_frame_sp;
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
ExecutionContextRef::ExecutionContextRef() :
m_target_wp (),
m_process_wp (),
m_thread_wp (),
<rdar://problem/13194155> Variables view out of sync with lldb in Xcode is now fixed. Depending on what happened stack frames could get out of date and a stale shared pointer (one that is no longer a current frame in a thread) could end up being used. Now we don't store a weak_ptr to a frame in the ExecutionContextRef class, we just store its stack ID and we always regrab the frame from the thread by stack ID. llvm-svn: 177208
2013-03-16 07:54:07 +08:00
m_tid(LLDB_INVALID_THREAD_ID),
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
m_stack_id ()
{
}
ExecutionContextRef::ExecutionContextRef (const ExecutionContext *exe_ctx) :
m_target_wp (),
m_process_wp (),
m_thread_wp (),
<rdar://problem/13194155> Variables view out of sync with lldb in Xcode is now fixed. Depending on what happened stack frames could get out of date and a stale shared pointer (one that is no longer a current frame in a thread) could end up being used. Now we don't store a weak_ptr to a frame in the ExecutionContextRef class, we just store its stack ID and we always regrab the frame from the thread by stack ID. llvm-svn: 177208
2013-03-16 07:54:07 +08:00
m_tid(LLDB_INVALID_THREAD_ID),
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
m_stack_id ()
{
if (exe_ctx)
*this = *exe_ctx;
}
ExecutionContextRef::ExecutionContextRef (const ExecutionContext &exe_ctx) :
m_target_wp (),
m_process_wp (),
m_thread_wp (),
<rdar://problem/13194155> Variables view out of sync with lldb in Xcode is now fixed. Depending on what happened stack frames could get out of date and a stale shared pointer (one that is no longer a current frame in a thread) could end up being used. Now we don't store a weak_ptr to a frame in the ExecutionContextRef class, we just store its stack ID and we always regrab the frame from the thread by stack ID. llvm-svn: 177208
2013-03-16 07:54:07 +08:00
m_tid(LLDB_INVALID_THREAD_ID),
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
m_stack_id ()
{
*this = exe_ctx;
}
ExecutionContextRef::ExecutionContextRef (Target *target, bool adopt_selected) :
m_target_wp(),
m_process_wp(),
m_thread_wp(),
<rdar://problem/13194155> Variables view out of sync with lldb in Xcode is now fixed. Depending on what happened stack frames could get out of date and a stale shared pointer (one that is no longer a current frame in a thread) could end up being used. Now we don't store a weak_ptr to a frame in the ExecutionContextRef class, we just store its stack ID and we always regrab the frame from the thread by stack ID. llvm-svn: 177208
2013-03-16 07:54:07 +08:00
m_tid(LLDB_INVALID_THREAD_ID),
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
m_stack_id ()
{
SetTargetPtr (target, adopt_selected);
}
ExecutionContextRef::ExecutionContextRef (const ExecutionContextRef &rhs) :
m_target_wp (rhs.m_target_wp),
m_process_wp(rhs.m_process_wp),
m_thread_wp (rhs.m_thread_wp),
m_tid (rhs.m_tid),
m_stack_id (rhs.m_stack_id)
{
}
ExecutionContextRef &
ExecutionContextRef::operator =(const ExecutionContextRef &rhs)
{
if (this != &rhs)
{
m_target_wp = rhs.m_target_wp;
m_process_wp = rhs.m_process_wp;
m_thread_wp = rhs.m_thread_wp;
m_tid = rhs.m_tid;
m_stack_id = rhs.m_stack_id;
}
return *this;
}
ExecutionContextRef &
ExecutionContextRef::operator =(const ExecutionContext &exe_ctx)
{
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_target_wp = exe_ctx.GetTargetSP();
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
m_process_wp = exe_ctx.GetProcessSP();
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
lldb::ThreadSP thread_sp (exe_ctx.GetThreadSP());
m_thread_wp = thread_sp;
if (thread_sp)
m_tid = thread_sp->GetID();
else
m_tid = LLDB_INVALID_THREAD_ID;
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
lldb::StackFrameSP frame_sp (exe_ctx.GetFrameSP());
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 (frame_sp)
m_stack_id = frame_sp->GetStackID();
else
m_stack_id.Clear();
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
return *this;
}
void
ExecutionContextRef::Clear()
{
m_target_wp.reset();
m_process_wp.reset();
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
ClearThread();
ClearFrame();
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
}
ExecutionContextRef::~ExecutionContextRef()
{
}
void
ExecutionContextRef::SetTargetSP (const lldb::TargetSP &target_sp)
{
m_target_wp = target_sp;
}
void
ExecutionContextRef::SetProcessSP (const lldb::ProcessSP &process_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
if (process_sp)
{
m_process_wp = process_sp;
SetTargetSP (process_sp->GetTarget().shared_from_this());
}
else
{
m_process_wp.reset();
m_target_wp.reset();
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
}
void
ExecutionContextRef::SetThreadSP (const lldb::ThreadSP &thread_sp)
{
if (thread_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_thread_wp = thread_sp;
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
m_tid = thread_sp->GetID();
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
SetProcessSP (thread_sp->GetProcess());
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
else
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
{
ClearThread();
m_process_wp.reset();
m_target_wp.reset();
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
}
void
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
ExecutionContextRef::SetFrameSP (const lldb::StackFrameSP &frame_sp)
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
{
if (frame_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
{
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
m_stack_id = frame_sp->GetStackID();
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
SetThreadSP (frame_sp->GetThread());
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
else
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
{
ClearFrame();
ClearThread();
m_process_wp.reset();
m_target_wp.reset();
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
}
void
ExecutionContextRef::SetTargetPtr (Target* target, bool adopt_selected)
{
Clear();
if (target)
{
lldb::TargetSP target_sp (target->shared_from_this());
if (target_sp)
{
m_target_wp = target_sp;
if (adopt_selected)
{
lldb::ProcessSP process_sp (target_sp->GetProcessSP());
if (process_sp)
{
m_process_wp = process_sp;
if (process_sp)
{
Don't set the thread when adopting selected execution context entries, and use the "lldb_private::StateIsStoppedState(StateType, bool)" function to tell if the state is stopped. llvm-svn: 161000
2012-07-31 06:05:39 +08:00
// Only fill in the thread and frame if our process is stopped
Fix a race condition where you could set the selected thread & target in the CommandInterpreter's execution context AFTER the process had started running and before it initially stopped. Also fixed one test case that was implicitly using this (and an abuse of the async mode) to accidentally succeed. <rdar://problem/16814726> llvm-svn: 226528
2015-01-20 07:51:51 +08:00
// Don't just check the state, since we might be in the middle of
// resuming.
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&process_sp->GetRunLock()) && StateIsStoppedState (process_sp->GetState(), true))
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
{
Don't set the thread when adopting selected execution context entries, and use the "lldb_private::StateIsStoppedState(StateType, bool)" function to tell if the state is stopped. llvm-svn: 161000
2012-07-31 06:05:39 +08:00
lldb::ThreadSP thread_sp (process_sp->GetThreadList().GetSelectedThread());
if (!thread_sp)
thread_sp = process_sp->GetThreadList().GetThreadAtIndex(0);
if (thread_sp)
{
SetThreadSP (thread_sp);
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
lldb::StackFrameSP frame_sp (thread_sp->GetSelectedFrame());
Don't set the thread when adopting selected execution context entries, and use the "lldb_private::StateIsStoppedState(StateType, bool)" function to tell if the state is stopped. llvm-svn: 161000
2012-07-31 06:05:39 +08:00
if (!frame_sp)
frame_sp = thread_sp->GetStackFrameAtIndex(0);
if (frame_sp)
SetFrameSP (frame_sp);
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
}
}
}
}
}
}
}
void
ExecutionContextRef::SetProcessPtr (Process *process)
{
if (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
{
SetProcessSP(process->shared_from_this());
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
else
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
{
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
m_process_wp.reset();
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_target_wp.reset();
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
}
void
ExecutionContextRef::SetThreadPtr (Thread *thread)
{
if (thread)
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
{
SetThreadSP (thread->shared_from_this());
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
else
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
{
ClearThread();
m_process_wp.reset();
m_target_wp.reset();
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
}
void
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
ExecutionContextRef::SetFramePtr (StackFrame *frame)
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
{
if (frame)
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
SetFrameSP (frame->shared_from_this());
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
else
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
Clear();
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +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
lldb::TargetSP
ExecutionContextRef::GetTargetSP () const
{
lldb::TargetSP target_sp(m_target_wp.lock());
if (target_sp && !target_sp->IsValid())
target_sp.reset();
return target_sp;
}
lldb::ProcessSP
ExecutionContextRef::GetProcessSP () const
{
lldb::ProcessSP process_sp(m_process_wp.lock());
if (process_sp && !process_sp->IsValid())
process_sp.reset();
return process_sp;
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
lldb::ThreadSP
ExecutionContextRef::GetThreadSP () const
{
lldb::ThreadSP thread_sp (m_thread_wp.lock());
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
<rdar://problem/11184458> Found an issue where we might still have shared pointer references to lldb_private::Thread objects where the object itself is not valid and has been removed from the Process. When a thread is removed from a process, it will call Thread::DestroyThread() which well set a boolean member variable which is exposed now via: bool Thread::IsValid() const; We then check the thread validity before handing out a shared pointer. llvm-svn: 154048
2012-04-05 04:43:47 +08:00
if (m_tid != LLDB_INVALID_THREAD_ID)
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
{
<rdar://problem/11184458> Found an issue where we might still have shared pointer references to lldb_private::Thread objects where the object itself is not valid and has been removed from the Process. When a thread is removed from a process, it will call Thread::DestroyThread() which well set a boolean member variable which is exposed now via: bool Thread::IsValid() const; We then check the thread validity before handing out a shared pointer. llvm-svn: 154048
2012-04-05 04:43:47 +08:00
// We check if the thread has been destroyed in cases where clients
// might still have shared pointer to a thread, but the thread is
// not valid anymore (not part of the process)
if (!thread_sp || !thread_sp->IsValid())
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
{
<rdar://problem/11184458> Found an issue where we might still have shared pointer references to lldb_private::Thread objects where the object itself is not valid and has been removed from the Process. When a thread is removed from a process, it will call Thread::DestroyThread() which well set a boolean member variable which is exposed now via: bool Thread::IsValid() const; We then check the thread validity before handing out a shared pointer. llvm-svn: 154048
2012-04-05 04:43:47 +08:00
lldb::ProcessSP process_sp(GetProcessSP());
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
if (process_sp && process_sp->IsValid())
<rdar://problem/11184458> Found an issue where we might still have shared pointer references to lldb_private::Thread objects where the object itself is not valid and has been removed from the Process. When a thread is removed from a process, it will call Thread::DestroyThread() which well set a boolean member variable which is exposed now via: bool Thread::IsValid() const; We then check the thread validity before handing out a shared pointer. llvm-svn: 154048
2012-04-05 04:43:47 +08:00
{
thread_sp = process_sp->GetThreadList().FindThreadByID(m_tid);
m_thread_wp = thread_sp;
}
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +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
// Check that we aren't about to return an invalid thread sp. We might return a NULL thread_sp,
// but don't return an invalid one.
if (thread_sp && !thread_sp->IsValid())
thread_sp.reset();
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
return thread_sp;
}
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
lldb::StackFrameSP
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
ExecutionContextRef::GetFrameSP () const
{
<rdar://problem/13643315> Fixed performance issues that arose after changing SBTarget, SBProcess, SBThread and SBFrame over to using a std::shared_ptr to a ExecutionContextRef. The ExecutionContextRef doesn't store a std::weak_ptr to a stack frame because stack frames often get replaced with new version, so it held onto a StackID object that would allow us to ask the thread each time for the frame for the StackID. The linear function was too slow for large recursive stacks. We also fixed an issue where anytime the std::shared_ptr<ExecutionContextRef> in any SBTarget, SBProcess, SBThread objects was turned into an ExecutionContext object, it would try to resolve all items in the ExecutionContext which are shared pointers. Even if the StackID in the ExecutionContextRef was invalid, it was looking through all frames in every thread. This causes a lot of unnecessary frame accesses. llvm-svn: 182627
2013-05-24 08:58:29 +08:00
if (m_stack_id.IsValid())
{
lldb::ThreadSP thread_sp (GetThreadSP());
if (thread_sp)
return thread_sp->GetFrameWithStackID (m_stack_id);
}
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
return lldb::StackFrameSP();
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
}
ExecutionContext
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
ExecutionContextRef::Lock (bool thread_and_frame_only_if_stopped) const
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
{
Merging the iohandler branch back into main. The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2014-01-28 07:43:24 +08:00
return ExecutionContext(this, thread_and_frame_only_if_stopped);
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
}