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

993 lines
30 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
//===-- SBFrame.cpp ---------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
And some more include line fixes. llvm-svn: 105704
2010-06-09 15:44:37 +08:00
#include "lldb/API/SBFrame.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include <string>
#include <algorithm>
#include "lldb/lldb-types.h"
#include "lldb/Core/Address.h"
#include "lldb/Core/ConstString.h"
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
#include "lldb/Core/Log.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/Stream.h"
#include "lldb/Core/StreamFile.h"
#include "lldb/Core/ValueObjectRegister.h"
#include "lldb/Core/ValueObjectVariable.h"
Added the notion that a value object can be constant by adding: bool ValueObject::GetIsConstant() const; void ValueObject::SetIsConstant(); This will stop anything from being re-evaluated within the value object so that constant result value objects can maintain their frozen values without anything being updated or changed within the value object. Made it so the ValueObjectConstResult can be constructed with an lldb_private::Error object to allow for expression results to have errors. Since ValueObject objects contain error objects, I changed the expression evaluation in ClangUserExpression from static Error ClangUserExpression::Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr, lldb::ValueObjectSP &result_valobj_sp); to: static lldb::ValueObjectSP Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr); Even though expression parsing is borked right now (pending fixes coming from Sean Callanan), I filled in the implementation for: SBValue SBFrame::EvaluateExpression (const char *expr); Modified all expression code to deal with the above changes. llvm-svn: 115589
2010-10-05 11:13:51 +08:00
#include "lldb/Expression/ClangUserExpression.h"
Bumped Xcode project versions to lldb-65 and debugserver-140. llvm-svn: 133865
2011-06-25 12:35:01 +08:00
#include "lldb/Host/Host.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Symbol/Block.h"
#include "lldb/Symbol/SymbolContext.h"
#include "lldb/Symbol/VariableList.h"
#include "lldb/Symbol/Variable.h"
#include "lldb/Target/ExecutionContext.h"
#include "lldb/Target/Target.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/RegisterContext.h"
#include "lldb/Target/StackFrame.h"
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
#include "lldb/Target/StackID.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Target/Thread.h"
And some more include line fixes. llvm-svn: 105704
2010-06-09 15:44:37 +08:00
#include "lldb/API/SBDebugger.h"
#include "lldb/API/SBValue.h"
#include "lldb/API/SBAddress.h"
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
#include "lldb/API/SBStream.h"
And some more include line fixes. llvm-svn: 105704
2010-06-09 15:44:37 +08:00
#include "lldb/API/SBSymbolContext.h"
#include "lldb/API/SBThread.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
namespace lldb_private {
class StackFrameImpl
{
public:
StackFrameImpl (const lldb::StackFrameSP &frame_sp) :
m_frame_wp (frame_sp),
m_thread_wp (),
m_stack_id ()
{
if (frame_sp)
{
m_thread_wp = frame_sp->GetThread().shared_from_this();
m_stack_id = frame_sp->GetStackID();
}
}
~StackFrameImpl()
{
}
lldb::StackFrameSP
GetFrameSP ()
{
lldb::StackFrameSP frame_sp;
// We have a weak pointer to our thread, which might
// be NULL'ed out if the thread went away, so first
// make sure our thread is still alive.
lldb::ThreadSP thread_sp (m_thread_wp.lock());
if (thread_sp)
{
// Our thread is still here, check if our frame
// is still alive as well.
frame_sp = m_frame_wp.lock();
if (frame_sp)
{
// Our frame is still alive, make sure that our thread
// still has this exact frame...
lldb::StackFrameSP tmp_frame_sp (thread_sp->GetStackFrameAtIndex (frame_sp->GetFrameIndex()));
if (tmp_frame_sp.get() == frame_sp.get())
return frame_sp;
}
// The original stack frame might have gone away,
// we need to check for the stac
frame_sp = thread_sp->GetFrameWithStackID (m_stack_id);
m_frame_wp = frame_sp;
}
return frame_sp;
}
void
SetFrameSP (const lldb::StackFrameSP &frame_sp)
{
if (frame_sp)
{
m_frame_wp = frame_sp;
m_thread_wp = frame_sp->GetThread().shared_from_this();
m_stack_id = frame_sp->GetStackID();
}
else
{
m_frame_wp.reset();
m_thread_wp.reset();
m_stack_id.Clear();
}
}
protected:
lldb::StackFrameWP m_frame_wp;
lldb::ThreadWP m_thread_wp;
StackID m_stack_id;
};
} // namespace lldb_private
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
using namespace lldb;
using namespace lldb_private;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBFrame::SBFrame () :
Very large changes that were needed in order to allow multiple connections to the debugger from GUI windows. Previously there was one global debugger instance that could be accessed that had its own command interpreter and current state (current target/process/thread/frame). When a GUI debugger was attached, if it opened more than one window that each had a console window, there were issues where the last one to setup the global debugger object won and got control of the debugger. To avoid this we now create instances of the lldb_private::Debugger that each has its own state: - target list for targets the debugger instance owns - current process/thread/frame - its own command interpreter - its own input, output and error file handles to avoid conflicts - its own input reader stack So now clients should call: SBDebugger::Initialize(); // (static function) SBDebugger debugger (SBDebugger::Create()); // Use which ever file handles you wish debugger.SetErrorFileHandle (stderr, false); debugger.SetOutputFileHandle (stdout, false); debugger.SetInputFileHandle (stdin, true); // main loop SBDebugger::Terminate(); // (static function) SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to ensure nothing gets destroyed too early when multiple clients might be attached. Cleaned up the command interpreter and the CommandObject and all subclasses to take more appropriate arguments. llvm-svn: 106615
2010-06-23 09:19:29 +08:00
m_opaque_sp ()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
SBFrame::SBFrame (const StackFrameSP &lldb_object_sp) :
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
m_opaque_sp (new StackFrameImpl (lldb_object_sp))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
{
SBStream sstr;
GetDescription (sstr);
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
log->Printf ("SBFrame::SBFrame (sp=%p) => SBFrame(%p): %s",
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
lldb_object_sp.get(), lldb_object_sp.get(), sstr.GetData());
Clean up the API logging code: - Try to reduce logging to one line per function call instead of tw - Put all arguments & their values into log for calls - Add 'this' parameter information to function call logging, making it show the appropriate internal pointer (this.obj, this.sp, this.ap...) - Clean up some return values - Remove logging of constructors that construct empty objects - Change '==>' to '=>' for showing result values... - Fix various minor bugs - Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments... llvm-svn: 117417
2010-10-27 07:49:36 +08:00
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added copy constructors and assignment operators to all lldb::SB* classes so we don't end up with weak exports with some compilers. llvm-svn: 118312
2010-11-06 07:17:00 +08:00
SBFrame::SBFrame(const SBFrame &rhs) :
m_opaque_sp (rhs.m_opaque_sp)
{
}
const SBFrame &
SBFrame::operator = (const SBFrame &rhs)
{
if (this != &rhs)
m_opaque_sp = rhs.m_opaque_sp;
return *this;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBFrame::~SBFrame()
{
}
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP
SBFrame::GetFrameSP() const
{
StackFrameImplSP impl_sp (m_opaque_sp);
StackFrameSP frame_sp;
if (impl_sp)
frame_sp = impl_sp->GetFrameSP();
return frame_sp;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
SBFrame::SetFrameSP (const StackFrameSP &lldb_object_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
if (lldb_object_sp)
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
if (m_opaque_sp)
{
StackFrameImplSP impl_sp (m_opaque_sp);
if (impl_sp)
impl_sp->SetFrameSP (lldb_object_sp);
}
else
{
m_opaque_sp = StackFrameImplSP (new StackFrameImpl(lldb_object_sp));
}
}
else
{
m_opaque_sp.reset();
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
bool
SBFrame::IsValid() const
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameImplSP impl_sp (m_opaque_sp);
if (impl_sp)
return (impl_sp->GetFrameSP().get() != NULL);
return false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
SBSymbolContext
SBFrame::GetSymbolContext (uint32_t resolve_scope) const
{
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBSymbolContext sb_sym_ctx;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
sb_sym_ctx.SetSymbolContext(&frame_sp->GetSymbolContext (resolve_scope));
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
log->Printf ("SBFrame(%p)::GetSymbolContext (resolve_scope=0x%8.8x) => SBSymbolContext(%p)",
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
frame_sp.get(), resolve_scope, sb_sym_ctx.get());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_sym_ctx;
}
SBModule
SBFrame::GetModule () const
{
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
SBModule sb_module;
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
ModuleSP module_sp;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
module_sp = frame_sp->GetSymbolContext (eSymbolContextModule).module_sp;
sb_module.SetSP (module_sp);
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
log->Printf ("SBFrame(%p)::GetModule () => SBModule(%p)",
lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still contain shared pointers to the lldb_private::Target and lldb_private::Process objects respectively as we won't want the target or process just going away. Also cleaned up the lldb::SBModule to remove dangerous pointer accessors. For any code the public API files, we should always be grabbing shared pointers to any objects for the current class, and any other classes prior to running code with them. llvm-svn: 149238
2012-01-30 17:04:36 +08:00
frame_sp.get(), module_sp.get());
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_module;
}
SBCompileUnit
SBFrame::GetCompileUnit () const
{
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
SBCompileUnit sb_comp_unit;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
sb_comp_unit.reset (frame_sp->GetSymbolContext (eSymbolContextCompUnit).comp_unit);
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
log->Printf ("SBFrame(%p)::GetModule () => SBCompileUnit(%p)",
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
frame_sp.get(), sb_comp_unit.get());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_comp_unit;
}
SBFunction
SBFrame::GetFunction () const
{
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
SBFunction sb_function;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
sb_function.reset(frame_sp->GetSymbolContext (eSymbolContextFunction).function);
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
log->Printf ("SBFrame(%p)::GetFunction () => SBFunction(%p)",
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
frame_sp.get(), sb_function.get());
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_function;
}
Added GetSymbol to the frame. llvm-svn: 115535
2010-10-05 02:37:52 +08:00
SBSymbol
SBFrame::GetSymbol () const
{
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
SBSymbol sb_symbol;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
sb_symbol.reset(frame_sp->GetSymbolContext (eSymbolContextSymbol).symbol);
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
log->Printf ("SBFrame(%p)::GetSymbol () => SBSymbol(%p)",
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
frame_sp.get(), sb_symbol.get());
Added GetSymbol to the frame. llvm-svn: 115535
2010-10-05 02:37:52 +08:00
return sb_symbol;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBBlock
SBFrame::GetBlock () const
{
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
SBBlock sb_block;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
Removed all of the "#ifndef SWIG" from the SB header files since we are using interface (.i) files for each class. Changed the FindFunction class from: uint32_t SBTarget::FindFunctions (const char *name, uint32_t name_type_mask, bool append, lldb::SBSymbolContextList& sc_list) uint32_t SBModule::FindFunctions (const char *name, uint32_t name_type_mask, bool append, lldb::SBSymbolContextList& sc_list) To: lldb::SBSymbolContextList SBTarget::FindFunctions (const char *name, uint32_t name_type_mask = lldb::eFunctionNameTypeAny); lldb::SBSymbolContextList SBModule::FindFunctions (const char *name, uint32_t name_type_mask = lldb::eFunctionNameTypeAny); This makes the API easier to use from python. Also added the ability to append a SBSymbolContext or a SBSymbolContextList to a SBSymbolContextList. Exposed properties for lldb.SBSymbolContextList in python: lldb.SBSymbolContextList.modules => list() or all lldb.SBModule objects in the list lldb.SBSymbolContextList.compile_units => list() or all lldb.SBCompileUnits objects in the list lldb.SBSymbolContextList.functions => list() or all lldb.SBFunction objects in the list lldb.SBSymbolContextList.blocks => list() or all lldb.SBBlock objects in the list lldb.SBSymbolContextList.line_entries => list() or all lldb.SBLineEntry objects in the list lldb.SBSymbolContextList.symbols => list() or all lldb.SBSymbol objects in the list This allows a call to the SBTarget::FindFunctions(...) and SBModule::FindFunctions(...) and then the result can be used to extract the desired information: sc_list = lldb.target.FindFunctions("erase") for function in sc_list.functions: print function for symbol in sc_list.symbols: print symbol Exposed properties for the lldb.SBSymbolContext objects in python: lldb.SBSymbolContext.module => lldb.SBModule lldb.SBSymbolContext.compile_unit => lldb.SBCompileUnit lldb.SBSymbolContext.function => lldb.SBFunction lldb.SBSymbolContext.block => lldb.SBBlock lldb.SBSymbolContext.line_entry => lldb.SBLineEntry lldb.SBSymbolContext.symbol => lldb.SBSymbol Exposed properties for the lldb.SBBlock objects in python: lldb.SBBlock.parent => lldb.SBBlock for the parent block that contains lldb.SBBlock.sibling => lldb.SBBlock for the sibling block to the current block lldb.SBBlock.first_child => lldb.SBBlock for the first child block to the current block lldb.SBBlock.call_site => for inline functions, return a lldb.declaration object that gives the call site file, line and column lldb.SBBlock.name => for inline functions this is the name of the inline function that this block represents lldb.SBBlock.inlined_block => returns the inlined function block that contains this block (might return itself if the current block is an inlined block) lldb.SBBlock.range[int] => access the address ranges for a block by index, a list() with start and end address is returned lldb.SBBlock.ranges => an array or all address ranges for this block lldb.SBBlock.num_ranges => the number of address ranges for this blcok SBFunction objects can now get the SBType and the SBBlock that represents the top scope of the function. SBBlock objects can now get the variable list from the current block. The value list returned allows varaibles to be viewed prior with no process if code wants to check the variables in a function. There are two ways to get a variable list from a SBBlock: lldb::SBValueList SBBlock::GetVariables (lldb::SBFrame& frame, bool arguments, bool locals, bool statics, lldb::DynamicValueType use_dynamic); lldb::SBValueList SBBlock::GetVariables (lldb::SBTarget& target, bool arguments, bool locals, bool statics); When a SBFrame is used, the values returned will be locked down to the frame and the values will be evaluated in the context of that frame. When a SBTarget is used, global an static variables can be viewed without a running process. llvm-svn: 149853
2012-02-06 09:44:54 +08:00
sb_block.SetPtr (frame_sp->GetSymbolContext (eSymbolContextBlock).block);
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
log->Printf ("SBFrame(%p)::GetBlock () => SBBlock(%p)",
Removed all of the "#ifndef SWIG" from the SB header files since we are using interface (.i) files for each class. Changed the FindFunction class from: uint32_t SBTarget::FindFunctions (const char *name, uint32_t name_type_mask, bool append, lldb::SBSymbolContextList& sc_list) uint32_t SBModule::FindFunctions (const char *name, uint32_t name_type_mask, bool append, lldb::SBSymbolContextList& sc_list) To: lldb::SBSymbolContextList SBTarget::FindFunctions (const char *name, uint32_t name_type_mask = lldb::eFunctionNameTypeAny); lldb::SBSymbolContextList SBModule::FindFunctions (const char *name, uint32_t name_type_mask = lldb::eFunctionNameTypeAny); This makes the API easier to use from python. Also added the ability to append a SBSymbolContext or a SBSymbolContextList to a SBSymbolContextList. Exposed properties for lldb.SBSymbolContextList in python: lldb.SBSymbolContextList.modules => list() or all lldb.SBModule objects in the list lldb.SBSymbolContextList.compile_units => list() or all lldb.SBCompileUnits objects in the list lldb.SBSymbolContextList.functions => list() or all lldb.SBFunction objects in the list lldb.SBSymbolContextList.blocks => list() or all lldb.SBBlock objects in the list lldb.SBSymbolContextList.line_entries => list() or all lldb.SBLineEntry objects in the list lldb.SBSymbolContextList.symbols => list() or all lldb.SBSymbol objects in the list This allows a call to the SBTarget::FindFunctions(...) and SBModule::FindFunctions(...) and then the result can be used to extract the desired information: sc_list = lldb.target.FindFunctions("erase") for function in sc_list.functions: print function for symbol in sc_list.symbols: print symbol Exposed properties for the lldb.SBSymbolContext objects in python: lldb.SBSymbolContext.module => lldb.SBModule lldb.SBSymbolContext.compile_unit => lldb.SBCompileUnit lldb.SBSymbolContext.function => lldb.SBFunction lldb.SBSymbolContext.block => lldb.SBBlock lldb.SBSymbolContext.line_entry => lldb.SBLineEntry lldb.SBSymbolContext.symbol => lldb.SBSymbol Exposed properties for the lldb.SBBlock objects in python: lldb.SBBlock.parent => lldb.SBBlock for the parent block that contains lldb.SBBlock.sibling => lldb.SBBlock for the sibling block to the current block lldb.SBBlock.first_child => lldb.SBBlock for the first child block to the current block lldb.SBBlock.call_site => for inline functions, return a lldb.declaration object that gives the call site file, line and column lldb.SBBlock.name => for inline functions this is the name of the inline function that this block represents lldb.SBBlock.inlined_block => returns the inlined function block that contains this block (might return itself if the current block is an inlined block) lldb.SBBlock.range[int] => access the address ranges for a block by index, a list() with start and end address is returned lldb.SBBlock.ranges => an array or all address ranges for this block lldb.SBBlock.num_ranges => the number of address ranges for this blcok SBFunction objects can now get the SBType and the SBBlock that represents the top scope of the function. SBBlock objects can now get the variable list from the current block. The value list returned allows varaibles to be viewed prior with no process if code wants to check the variables in a function. There are two ways to get a variable list from a SBBlock: lldb::SBValueList SBBlock::GetVariables (lldb::SBFrame& frame, bool arguments, bool locals, bool statics, lldb::DynamicValueType use_dynamic); lldb::SBValueList SBBlock::GetVariables (lldb::SBTarget& target, bool arguments, bool locals, bool statics); When a SBFrame is used, the values returned will be locked down to the frame and the values will be evaluated in the context of that frame. When a SBTarget is used, global an static variables can be viewed without a running process. llvm-svn: 149853
2012-02-06 09:44:54 +08:00
frame_sp.get(), sb_block.GetPtr());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_block;
}
Added more API to lldb::SBBlock to allow getting the block parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
2010-09-07 12:20:48 +08:00
SBBlock
SBFrame::GetFrameBlock () const
{
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
SBBlock sb_block;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
Removed all of the "#ifndef SWIG" from the SB header files since we are using interface (.i) files for each class. Changed the FindFunction class from: uint32_t SBTarget::FindFunctions (const char *name, uint32_t name_type_mask, bool append, lldb::SBSymbolContextList& sc_list) uint32_t SBModule::FindFunctions (const char *name, uint32_t name_type_mask, bool append, lldb::SBSymbolContextList& sc_list) To: lldb::SBSymbolContextList SBTarget::FindFunctions (const char *name, uint32_t name_type_mask = lldb::eFunctionNameTypeAny); lldb::SBSymbolContextList SBModule::FindFunctions (const char *name, uint32_t name_type_mask = lldb::eFunctionNameTypeAny); This makes the API easier to use from python. Also added the ability to append a SBSymbolContext or a SBSymbolContextList to a SBSymbolContextList. Exposed properties for lldb.SBSymbolContextList in python: lldb.SBSymbolContextList.modules => list() or all lldb.SBModule objects in the list lldb.SBSymbolContextList.compile_units => list() or all lldb.SBCompileUnits objects in the list lldb.SBSymbolContextList.functions => list() or all lldb.SBFunction objects in the list lldb.SBSymbolContextList.blocks => list() or all lldb.SBBlock objects in the list lldb.SBSymbolContextList.line_entries => list() or all lldb.SBLineEntry objects in the list lldb.SBSymbolContextList.symbols => list() or all lldb.SBSymbol objects in the list This allows a call to the SBTarget::FindFunctions(...) and SBModule::FindFunctions(...) and then the result can be used to extract the desired information: sc_list = lldb.target.FindFunctions("erase") for function in sc_list.functions: print function for symbol in sc_list.symbols: print symbol Exposed properties for the lldb.SBSymbolContext objects in python: lldb.SBSymbolContext.module => lldb.SBModule lldb.SBSymbolContext.compile_unit => lldb.SBCompileUnit lldb.SBSymbolContext.function => lldb.SBFunction lldb.SBSymbolContext.block => lldb.SBBlock lldb.SBSymbolContext.line_entry => lldb.SBLineEntry lldb.SBSymbolContext.symbol => lldb.SBSymbol Exposed properties for the lldb.SBBlock objects in python: lldb.SBBlock.parent => lldb.SBBlock for the parent block that contains lldb.SBBlock.sibling => lldb.SBBlock for the sibling block to the current block lldb.SBBlock.first_child => lldb.SBBlock for the first child block to the current block lldb.SBBlock.call_site => for inline functions, return a lldb.declaration object that gives the call site file, line and column lldb.SBBlock.name => for inline functions this is the name of the inline function that this block represents lldb.SBBlock.inlined_block => returns the inlined function block that contains this block (might return itself if the current block is an inlined block) lldb.SBBlock.range[int] => access the address ranges for a block by index, a list() with start and end address is returned lldb.SBBlock.ranges => an array or all address ranges for this block lldb.SBBlock.num_ranges => the number of address ranges for this blcok SBFunction objects can now get the SBType and the SBBlock that represents the top scope of the function. SBBlock objects can now get the variable list from the current block. The value list returned allows varaibles to be viewed prior with no process if code wants to check the variables in a function. There are two ways to get a variable list from a SBBlock: lldb::SBValueList SBBlock::GetVariables (lldb::SBFrame& frame, bool arguments, bool locals, bool statics, lldb::DynamicValueType use_dynamic); lldb::SBValueList SBBlock::GetVariables (lldb::SBTarget& target, bool arguments, bool locals, bool statics); When a SBFrame is used, the values returned will be locked down to the frame and the values will be evaluated in the context of that frame. When a SBTarget is used, global an static variables can be viewed without a running process. llvm-svn: 149853
2012-02-06 09:44:54 +08:00
sb_block.SetPtr(frame_sp->GetFrameBlock ());
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
log->Printf ("SBFrame(%p)::GetFrameBlock () => SBBlock(%p)",
Removed all of the "#ifndef SWIG" from the SB header files since we are using interface (.i) files for each class. Changed the FindFunction class from: uint32_t SBTarget::FindFunctions (const char *name, uint32_t name_type_mask, bool append, lldb::SBSymbolContextList& sc_list) uint32_t SBModule::FindFunctions (const char *name, uint32_t name_type_mask, bool append, lldb::SBSymbolContextList& sc_list) To: lldb::SBSymbolContextList SBTarget::FindFunctions (const char *name, uint32_t name_type_mask = lldb::eFunctionNameTypeAny); lldb::SBSymbolContextList SBModule::FindFunctions (const char *name, uint32_t name_type_mask = lldb::eFunctionNameTypeAny); This makes the API easier to use from python. Also added the ability to append a SBSymbolContext or a SBSymbolContextList to a SBSymbolContextList. Exposed properties for lldb.SBSymbolContextList in python: lldb.SBSymbolContextList.modules => list() or all lldb.SBModule objects in the list lldb.SBSymbolContextList.compile_units => list() or all lldb.SBCompileUnits objects in the list lldb.SBSymbolContextList.functions => list() or all lldb.SBFunction objects in the list lldb.SBSymbolContextList.blocks => list() or all lldb.SBBlock objects in the list lldb.SBSymbolContextList.line_entries => list() or all lldb.SBLineEntry objects in the list lldb.SBSymbolContextList.symbols => list() or all lldb.SBSymbol objects in the list This allows a call to the SBTarget::FindFunctions(...) and SBModule::FindFunctions(...) and then the result can be used to extract the desired information: sc_list = lldb.target.FindFunctions("erase") for function in sc_list.functions: print function for symbol in sc_list.symbols: print symbol Exposed properties for the lldb.SBSymbolContext objects in python: lldb.SBSymbolContext.module => lldb.SBModule lldb.SBSymbolContext.compile_unit => lldb.SBCompileUnit lldb.SBSymbolContext.function => lldb.SBFunction lldb.SBSymbolContext.block => lldb.SBBlock lldb.SBSymbolContext.line_entry => lldb.SBLineEntry lldb.SBSymbolContext.symbol => lldb.SBSymbol Exposed properties for the lldb.SBBlock objects in python: lldb.SBBlock.parent => lldb.SBBlock for the parent block that contains lldb.SBBlock.sibling => lldb.SBBlock for the sibling block to the current block lldb.SBBlock.first_child => lldb.SBBlock for the first child block to the current block lldb.SBBlock.call_site => for inline functions, return a lldb.declaration object that gives the call site file, line and column lldb.SBBlock.name => for inline functions this is the name of the inline function that this block represents lldb.SBBlock.inlined_block => returns the inlined function block that contains this block (might return itself if the current block is an inlined block) lldb.SBBlock.range[int] => access the address ranges for a block by index, a list() with start and end address is returned lldb.SBBlock.ranges => an array or all address ranges for this block lldb.SBBlock.num_ranges => the number of address ranges for this blcok SBFunction objects can now get the SBType and the SBBlock that represents the top scope of the function. SBBlock objects can now get the variable list from the current block. The value list returned allows varaibles to be viewed prior with no process if code wants to check the variables in a function. There are two ways to get a variable list from a SBBlock: lldb::SBValueList SBBlock::GetVariables (lldb::SBFrame& frame, bool arguments, bool locals, bool statics, lldb::DynamicValueType use_dynamic); lldb::SBValueList SBBlock::GetVariables (lldb::SBTarget& target, bool arguments, bool locals, bool statics); When a SBFrame is used, the values returned will be locked down to the frame and the values will be evaluated in the context of that frame. When a SBTarget is used, global an static variables can be viewed without a running process. llvm-svn: 149853
2012-02-06 09:44:54 +08:00
frame_sp.get(), sb_block.GetPtr());
Added more API to lldb::SBBlock to allow getting the block parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
2010-09-07 12:20:48 +08:00
return sb_block;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBLineEntry
SBFrame::GetLineEntry () const
{
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
SBLineEntry sb_line_entry;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
sb_line_entry.SetLineEntry (frame_sp->GetSymbolContext (eSymbolContextLineEntry).line_entry);
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
log->Printf ("SBFrame(%p)::GetLineEntry () => SBLineEntry(%p)",
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
frame_sp.get(), sb_line_entry.get());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_line_entry;
}
uint32_t
SBFrame::GetFrameID () const
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
uint32_t frame_idx = UINT32_MAX;
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
frame_idx = frame_sp->GetFrameIndex ();
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
log->Printf ("SBFrame(%p)::GetFrameID () => %u",
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
frame_sp.get(), frame_idx);
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
return frame_idx;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
addr_t
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBFrame::GetPC () const
{
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
addr_t addr = LLDB_INVALID_ADDRESS;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
addr = frame_sp->GetFrameCodeAddress().GetOpcodeLoadAddress (&frame_sp->GetThread().GetProcess().GetTarget());
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
log->Printf ("SBFrame(%p)::GetPC () => 0x%llx", frame_sp.get(), addr);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
return addr;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
bool
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
SBFrame::SetPC (addr_t new_pc)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
bool ret_val = false;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
ret_val = frame_sp->GetRegisterContext()->SetPC (new_pc);
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
log->Printf ("SBFrame(%p)::SetPC (new_pc=0x%llx) => %i",
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
frame_sp.get(), new_pc, ret_val);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
return ret_val;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
addr_t
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBFrame::GetSP () const
{
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
addr_t addr = LLDB_INVALID_ADDRESS;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
addr = frame_sp->GetRegisterContext()->GetSP();
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
log->Printf ("SBFrame(%p)::GetSP () => 0x%llx", frame_sp.get(), addr);
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
return addr;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
addr_t
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBFrame::GetFP () const
{
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
addr_t addr = LLDB_INVALID_ADDRESS;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
addr = frame_sp->GetRegisterContext()->GetFP();
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
log->Printf ("SBFrame(%p)::GetFP () => 0x%llx", frame_sp.get(), addr);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
return addr;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
SBAddress
SBFrame::GetPCAddress () const
{
SBAddress sb_addr;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
sb_addr.SetAddress (&frame_sp->GetFrameCodeAddress());
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
log->Printf ("SBFrame(%p)::GetPCAddress () => SBAddress(%p)", frame_sp.get(), sb_addr.get());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_addr;
}
void
SBFrame::Clear()
{
Very large changes that were needed in order to allow multiple connections to the debugger from GUI windows. Previously there was one global debugger instance that could be accessed that had its own command interpreter and current state (current target/process/thread/frame). When a GUI debugger was attached, if it opened more than one window that each had a console window, there were issues where the last one to setup the global debugger object won and got control of the debugger. To avoid this we now create instances of the lldb_private::Debugger that each has its own state: - target list for targets the debugger instance owns - current process/thread/frame - its own command interpreter - its own input, output and error file handles to avoid conflicts - its own input reader stack So now clients should call: SBDebugger::Initialize(); // (static function) SBDebugger debugger (SBDebugger::Create()); // Use which ever file handles you wish debugger.SetErrorFileHandle (stderr, false); debugger.SetOutputFileHandle (stdout, false); debugger.SetInputFileHandle (stdin, true); // main loop SBDebugger::Terminate(); // (static function) SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to ensure nothing gets destroyed too early when multiple clients might be attached. Cleaned up the command interpreter and the CommandObject and all subclasses to take more appropriate arguments. llvm-svn: 106615
2010-06-23 09:19:29 +08:00
m_opaque_sp.reset();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Expose more convenience functionality in the python classes. lldb.SBValueList now exposes the len() method and also allows item access: lldb.SBValueList[<int>] - where <int> is an integer index into the list, returns a single lldb.SBValue which might be empty if the index is out of range lldb.SBValueList[<str>] - where <str> is the name to look for, returns a list() of lldb.SBValue objects with any matching values (the list might be empty if nothing matches) lldb.SBValueList[<re>] - where <re> is a compiles regular expression, returns a list of lldb.SBValue objects for containing any matches or a empty list if nothing matches lldb.SBFrame now exposes: lldb.SBFrame.variables => SBValueList of all variables that are in scope lldb.SBFrame.vars => see lldb.SBFrame.variables lldb.SBFrame.locals => SBValueList of all variables that are locals in the current frame lldb.SBFrame.arguments => SBValueList of all variables that are arguments in the current frame lldb.SBFrame.args => see lldb.SBFrame.arguments lldb.SBFrame.statics => SBValueList of all static variables lldb.SBFrame.registers => SBValueList of all registers for the current frame lldb.SBFrame.regs => see lldb.SBFrame.registers Combine any of the above properties with the new lldb.SBValueList functionality and now you can do: y = lldb.frame.vars['rect.origin.y'] or vars = lldb.frame.vars for i in range len(vars): print vars[i] Also expose "lldb.SBFrame.var(<str>)" where <str> can be en expression path for any variable or child within the variable. This makes it easier to get a value from the current frame like "rect.origin.y". The resulting value is also not a constant result as expressions will return, but a live value that will continue to track the current value for the variable expression path. lldb.SBValue now exposes: lldb.SBValue.unsigned => unsigned integer for the value lldb.SBValue.signed => a signed integer for the value llvm-svn: 149684
2012-02-03 15:02:37 +08:00
lldb::SBValue
SBFrame::GetValueForVariablePath (const char *var_path)
{
SBValue sb_value;
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
{
lldb::DynamicValueType use_dynamic = frame_sp->CalculateTarget()->GetPreferDynamicValue();
sb_value = GetValueForVariablePath (var_path, use_dynamic);
}
return sb_value;
}
lldb::SBValue
SBFrame::GetValueForVariablePath (const char *var_path, DynamicValueType use_dynamic)
{
SBValue sb_value;
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp && var_path && var_path[0])
{
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
VariableSP var_sp;
Error error;
ValueObjectSP value_sp (frame_sp->GetValueForVariableExpressionPath (var_path,
use_dynamic,
StackFrame::eExpressionPathOptionCheckPtrVsMember,
var_sp,
error));
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
sb_value.SetSP(value_sp);
Expose more convenience functionality in the python classes. lldb.SBValueList now exposes the len() method and also allows item access: lldb.SBValueList[<int>] - where <int> is an integer index into the list, returns a single lldb.SBValue which might be empty if the index is out of range lldb.SBValueList[<str>] - where <str> is the name to look for, returns a list() of lldb.SBValue objects with any matching values (the list might be empty if nothing matches) lldb.SBValueList[<re>] - where <re> is a compiles regular expression, returns a list of lldb.SBValue objects for containing any matches or a empty list if nothing matches lldb.SBFrame now exposes: lldb.SBFrame.variables => SBValueList of all variables that are in scope lldb.SBFrame.vars => see lldb.SBFrame.variables lldb.SBFrame.locals => SBValueList of all variables that are locals in the current frame lldb.SBFrame.arguments => SBValueList of all variables that are arguments in the current frame lldb.SBFrame.args => see lldb.SBFrame.arguments lldb.SBFrame.statics => SBValueList of all static variables lldb.SBFrame.registers => SBValueList of all registers for the current frame lldb.SBFrame.regs => see lldb.SBFrame.registers Combine any of the above properties with the new lldb.SBValueList functionality and now you can do: y = lldb.frame.vars['rect.origin.y'] or vars = lldb.frame.vars for i in range len(vars): print vars[i] Also expose "lldb.SBFrame.var(<str>)" where <str> can be en expression path for any variable or child within the variable. This makes it easier to get a value from the current frame like "rect.origin.y". The resulting value is also not a constant result as expressions will return, but a live value that will continue to track the current value for the variable expression path. lldb.SBValue now exposes: lldb.SBValue.unsigned => unsigned integer for the value lldb.SBValue.signed => a signed integer for the value llvm-svn: 149684
2012-02-03 15:02:37 +08:00
}
return sb_value;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBValue
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
SBFrame::FindVariable (const char *name)
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
{
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
SBValue value;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
lldb::DynamicValueType use_dynamic = frame_sp->CalculateTarget()->GetPreferDynamicValue();
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
value = FindVariable (name, use_dynamic);
}
return value;
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
}
Expose more convenience functionality in the python classes. lldb.SBValueList now exposes the len() method and also allows item access: lldb.SBValueList[<int>] - where <int> is an integer index into the list, returns a single lldb.SBValue which might be empty if the index is out of range lldb.SBValueList[<str>] - where <str> is the name to look for, returns a list() of lldb.SBValue objects with any matching values (the list might be empty if nothing matches) lldb.SBValueList[<re>] - where <re> is a compiles regular expression, returns a list of lldb.SBValue objects for containing any matches or a empty list if nothing matches lldb.SBFrame now exposes: lldb.SBFrame.variables => SBValueList of all variables that are in scope lldb.SBFrame.vars => see lldb.SBFrame.variables lldb.SBFrame.locals => SBValueList of all variables that are locals in the current frame lldb.SBFrame.arguments => SBValueList of all variables that are arguments in the current frame lldb.SBFrame.args => see lldb.SBFrame.arguments lldb.SBFrame.statics => SBValueList of all static variables lldb.SBFrame.registers => SBValueList of all registers for the current frame lldb.SBFrame.regs => see lldb.SBFrame.registers Combine any of the above properties with the new lldb.SBValueList functionality and now you can do: y = lldb.frame.vars['rect.origin.y'] or vars = lldb.frame.vars for i in range len(vars): print vars[i] Also expose "lldb.SBFrame.var(<str>)" where <str> can be en expression path for any variable or child within the variable. This makes it easier to get a value from the current frame like "rect.origin.y". The resulting value is also not a constant result as expressions will return, but a live value that will continue to track the current value for the variable expression path. lldb.SBValue now exposes: lldb.SBValue.unsigned => unsigned integer for the value lldb.SBValue.signed => a signed integer for the value llvm-svn: 149684
2012-02-03 15:02:37 +08:00
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
SBValue
Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay). Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target, and dynamic with running target. llvm-svn: 130832
2011-05-04 11:43:18 +08:00
SBFrame::FindVariable (const char *name, lldb::DynamicValueType use_dynamic)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
VariableSP var_sp;
Fix up how the ValueObjects manage their life cycle so that you can hand out a shared pointer to a ValueObject or any of its dependent ValueObjects, and the whole cluster will stay around as long as that shared pointer stays around. llvm-svn: 130035
2011-04-23 07:53:53 +08:00
SBValue sb_value;
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
ValueObjectSP value_sp;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp && name && name[0])
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
VariableList variable_list;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
SymbolContext sc (frame_sp->GetSymbolContext (eSymbolContextBlock));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
if (sc.block)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
const bool can_create = true;
const bool get_parent_variables = true;
const bool stop_if_block_is_inlined_function = true;
if (sc.block->AppendVariables (can_create,
get_parent_variables,
stop_if_block_is_inlined_function,
&variable_list))
{
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
var_sp = variable_list.FindVariable (ConstString(name));
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
if (var_sp)
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
{
value_sp = frame_sp->GetValueObjectForFrameVariable(var_sp, use_dynamic);
sb_value.SetSP(value_sp);
}
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
log->Printf ("SBFrame(%p)::FindVariable (name=\"%s\") => SBValue(%p)",
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
frame_sp.get(), name, value_sp.get());
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_value;
}
SBValue
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
SBFrame::FindValue (const char *name, ValueType value_type)
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
{
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
SBValue value;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
lldb::DynamicValueType use_dynamic = frame_sp->CalculateTarget()->GetPreferDynamicValue();
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
value = FindValue (name, value_type, use_dynamic);
}
return value;
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
}
SBValue
Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay). Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target, and dynamic with running target. llvm-svn: 130832
2011-05-04 11:43:18 +08:00
SBFrame::FindValue (const char *name, ValueType value_type, lldb::DynamicValueType use_dynamic)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
SBValue sb_value;
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
ValueObjectSP value_sp;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp && name && name[0])
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
switch (value_type)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
case eValueTypeVariableGlobal: // global variable
case eValueTypeVariableStatic: // static variable
case eValueTypeVariableArgument: // function argument variables
case eValueTypeVariableLocal: // function local variables
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
VariableList *variable_list = frame_sp->GetVariableList(true);
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
SymbolContext sc (frame_sp->GetSymbolContext (eSymbolContextBlock));
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
const bool can_create = true;
const bool get_parent_variables = true;
const bool stop_if_block_is_inlined_function = true;
if (sc.block && sc.block->AppendVariables (can_create,
get_parent_variables,
stop_if_block_is_inlined_function,
variable_list))
{
ConstString const_name(name);
const uint32_t num_variables = variable_list->GetSize();
for (uint32_t i = 0; i < num_variables; ++i)
{
VariableSP variable_sp (variable_list->GetVariableAtIndex(i));
if (variable_sp &&
variable_sp->GetScope() == value_type &&
variable_sp->GetName() == const_name)
{
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
value_sp = frame_sp->GetValueObjectForFrameVariable (variable_sp, use_dynamic);
sb_value.SetSP (value_sp);
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
break;
}
}
}
}
break;
case eValueTypeRegister: // stack frame register value
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
RegisterContextSP reg_ctx (frame_sp->GetRegisterContext());
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
if (reg_ctx)
{
const uint32_t num_regs = reg_ctx->GetRegisterCount();
for (uint32_t reg_idx = 0; reg_idx < num_regs; ++reg_idx)
{
const RegisterInfo *reg_info = reg_ctx->GetRegisterInfoAtIndex (reg_idx);
if (reg_info &&
((reg_info->name && strcasecmp (reg_info->name, name) == 0) ||
(reg_info->alt_name && strcasecmp (reg_info->alt_name, name) == 0)))
{
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
value_sp = ValueObjectRegister::Create (frame_sp.get(), reg_ctx, reg_idx);
sb_value.SetSP (value_sp);
break;
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
}
}
}
}
break;
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
case eValueTypeRegisterSet: // A collection of stack frame register values
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
RegisterContextSP reg_ctx (frame_sp->GetRegisterContext());
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
if (reg_ctx)
Fill in more test sequences for Python API SBFrame.LookupVarInScope(name, scope). Change SBFrame::LookupVarInScope() to also work with "global" scope in addition to "local" and "parameter" scope. llvm-svn: 119811
2010-11-20 02:07:14 +08:00
{
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
const uint32_t num_sets = reg_ctx->GetRegisterSetCount();
for (uint32_t set_idx = 0; set_idx < num_sets; ++set_idx)
Fill in more test sequences for Python API SBFrame.LookupVarInScope(name, scope). Change SBFrame::LookupVarInScope() to also work with "global" scope in addition to "local" and "parameter" scope. llvm-svn: 119811
2010-11-20 02:07:14 +08:00
{
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
const RegisterSet *reg_set = reg_ctx->GetRegisterSet (set_idx);
if (reg_set &&
((reg_set->name && strcasecmp (reg_set->name, name) == 0) ||
(reg_set->short_name && strcasecmp (reg_set->short_name, name) == 0)))
{
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
value_sp = ValueObjectRegisterSet::Create (frame_sp.get(), reg_ctx, set_idx);
sb_value.SetSP (value_sp);
break;
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
}
Fill in more test sequences for Python API SBFrame.LookupVarInScope(name, scope). Change SBFrame::LookupVarInScope() to also work with "global" scope in addition to "local" and "parameter" scope. llvm-svn: 119811
2010-11-20 02:07:14 +08:00
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
break;
case eValueTypeConstResult: // constant result variables
{
ConstString const_name(name);
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
ClangExpressionVariableSP expr_var_sp (frame_sp->GetThread().GetProcess().GetTarget().GetPersistentVariables().GetVariable (const_name));
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
if (expr_var_sp)
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
{
value_sp = expr_var_sp->GetValueObject();
sb_value.SetSP (value_sp);
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
}
break;
default:
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
log->Printf ("SBFrame(%p)::FindVariableInScope (name=\"%s\", value_type=%i) => SBValue(%p)",
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
frame_sp.get(), name, value_type, value_sp.get());
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_value;
}
bool
SBFrame::operator == (const SBFrame &rhs) const
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
return GetFrameSP().get() == rhs.GetFrameSP().get();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
bool
SBFrame::operator != (const SBFrame &rhs) const
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
return GetFrameSP().get() != rhs.GetFrameSP().get();
Added support for stepping out of a frame. If you have 10 stack frames, and you select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
2011-01-21 14:11:58 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBThread
SBFrame::GetThread () const
{
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp object before trying to use it. llvm-svn: 121748
2010-12-14 12:58:53 +08:00
SBThread sb_thread;
Removed the "lldb-forward-rtti.h" header file as it was designed to contain all RTTI types, and since we don't use RTTI anymore since clang and llvm don't we don't really need this header file. All shared pointer definitions have been moved into "lldb-forward.h". Defined std::tr1::weak_ptr definitions for all of the types that inherit from enable_shared_from_this() in "lldb-forward.h" in preparation for thread hardening our public API. The first in the thread hardening check-ins. First we start with SBThread. We have issues in our lldb::SB API right now where if you have one object that is being used by two threads we have a race condition. Consider the following code: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 if (m_opaque_sp) 6 { 7 result = m_opaque_sp->DoSomething(); 8 } 9 return result; 10 } And now this happens: Thread 1 enters any SBThread function and checks its m_opaque_sp and is about to execute the code on line 7 but hasn't yet Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear() and clears the contents of the shared pointer member Thread 1 now crashes when it resumes. The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this function would look like: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 ThreadSP thread_sp(m_opaque_wp.lock()); 6 if (thread_sp) 7 { 8 result = m_opaque_sp->DoSomething(); 9 } 10 return result; 11 } Now we have a solid thread safe API where we get a local copy of our thread shared pointer from our weak_ptr and then we are guaranteed it can't go away during our function. So lldb::SBThread has been thread hardened, more checkins to follow shortly. llvm-svn: 149218
2012-01-30 10:53:15 +08:00
ThreadSP thread_sp;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
thread_sp = frame_sp->GetThread().shared_from_this();
Removed the "lldb-forward-rtti.h" header file as it was designed to contain all RTTI types, and since we don't use RTTI anymore since clang and llvm don't we don't really need this header file. All shared pointer definitions have been moved into "lldb-forward.h". Defined std::tr1::weak_ptr definitions for all of the types that inherit from enable_shared_from_this() in "lldb-forward.h" in preparation for thread hardening our public API. The first in the thread hardening check-ins. First we start with SBThread. We have issues in our lldb::SB API right now where if you have one object that is being used by two threads we have a race condition. Consider the following code: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 if (m_opaque_sp) 6 { 7 result = m_opaque_sp->DoSomething(); 8 } 9 return result; 10 } And now this happens: Thread 1 enters any SBThread function and checks its m_opaque_sp and is about to execute the code on line 7 but hasn't yet Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear() and clears the contents of the shared pointer member Thread 1 now crashes when it resumes. The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this function would look like: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 ThreadSP thread_sp(m_opaque_wp.lock()); 6 if (thread_sp) 7 { 8 result = m_opaque_sp->DoSomething(); 9 } 10 return result; 11 } Now we have a solid thread safe API where we get a local copy of our thread shared pointer from our weak_ptr and then we are guaranteed it can't go away during our function. So lldb::SBThread has been thread hardened, more checkins to follow shortly. llvm-svn: 149218
2012-01-30 10:53:15 +08:00
sb_thread.SetThread (thread_sp);
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
Clean up the API logging code: - Try to reduce logging to one line per function call instead of tw - Put all arguments & their values into log for calls - Add 'this' parameter information to function call logging, making it show the appropriate internal pointer (this.obj, this.sp, this.ap...) - Clean up some return values - Remove logging of constructors that construct empty objects - Change '==>' to '=>' for showing result values... - Fix various minor bugs - Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments... llvm-svn: 117417
2010-10-27 07:49:36 +08:00
{
SBStream sstr;
sb_thread.GetDescription (sstr);
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
log->Printf ("SBFrame(%p)::GetThread () => SBThread(%p): %s", frame_sp.get(),
Removed the "lldb-forward-rtti.h" header file as it was designed to contain all RTTI types, and since we don't use RTTI anymore since clang and llvm don't we don't really need this header file. All shared pointer definitions have been moved into "lldb-forward.h". Defined std::tr1::weak_ptr definitions for all of the types that inherit from enable_shared_from_this() in "lldb-forward.h" in preparation for thread hardening our public API. The first in the thread hardening check-ins. First we start with SBThread. We have issues in our lldb::SB API right now where if you have one object that is being used by two threads we have a race condition. Consider the following code: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 if (m_opaque_sp) 6 { 7 result = m_opaque_sp->DoSomething(); 8 } 9 return result; 10 } And now this happens: Thread 1 enters any SBThread function and checks its m_opaque_sp and is about to execute the code on line 7 but hasn't yet Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear() and clears the contents of the shared pointer member Thread 1 now crashes when it resumes. The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this function would look like: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 ThreadSP thread_sp(m_opaque_wp.lock()); 6 if (thread_sp) 7 { 8 result = m_opaque_sp->DoSomething(); 9 } 10 return result; 11 } Now we have a solid thread safe API where we get a local copy of our thread shared pointer from our weak_ptr and then we are guaranteed it can't go away during our function. So lldb::SBThread has been thread hardened, more checkins to follow shortly. llvm-svn: 149218
2012-01-30 10:53:15 +08:00
thread_sp.get(), sstr.GetData());
Clean up the API logging code: - Try to reduce logging to one line per function call instead of tw - Put all arguments & their values into log for calls - Add 'this' parameter information to function call logging, making it show the appropriate internal pointer (this.obj, this.sp, this.ap...) - Clean up some return values - Remove logging of constructors that construct empty objects - Change '==>' to '=>' for showing result values... - Fix various minor bugs - Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments... llvm-svn: 117417
2010-10-27 07:49:36 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return sb_thread;
}
const char *
SBFrame::Disassemble () const
{
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
const char *disassembly = NULL;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
disassembly = frame_sp->Disassemble();
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
log->Printf ("SBFrame(%p)::Disassemble () => %s", frame_sp.get(), disassembly);
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
return disassembly;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
SBValueList
SBFrame::GetVariables (bool arguments,
bool locals,
bool statics,
bool in_scope_only)
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
{
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
SBValueList value_list;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
lldb::DynamicValueType use_dynamic = frame_sp->CalculateTarget()->GetPreferDynamicValue();
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
value_list = GetVariables (arguments, locals, statics, in_scope_only, use_dynamic);
}
return value_list;
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
}
SBValueList
SBFrame::GetVariables (bool arguments,
bool locals,
bool statics,
bool in_scope_only,
Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay). Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target, and dynamic with running target. llvm-svn: 130832
2011-05-04 11:43:18 +08:00
lldb::DynamicValueType use_dynamic)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
SBValueList value_list;
StackFrameSP frame_sp(GetFrameSP());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
log->Printf ("SBFrame(%p)::GetVariables (arguments=%i, locals=%i, statics=%i, in_scope_only=%i)",
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
frame_sp.get(),
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
arguments,
locals,
statics,
in_scope_only);
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
if (frame_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
size_t i;
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
VariableList *variable_list = NULL;
// Scope for locker
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
variable_list = frame_sp->GetVariableList(true);
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (variable_list)
{
const size_t num_variables = variable_list->GetSize();
if (num_variables)
{
for (i = 0; i < num_variables; ++i)
{
VariableSP variable_sp (variable_list->GetVariableAtIndex(i));
if (variable_sp)
{
bool add_variable = false;
switch (variable_sp->GetScope())
{
case eValueTypeVariableGlobal:
case eValueTypeVariableStatic:
add_variable = statics;
break;
case eValueTypeVariableArgument:
add_variable = arguments;
break;
case eValueTypeVariableLocal:
add_variable = locals;
break;
Merged Eli Friedman's linux build changes where he added Makefile files that enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
2010-07-10 04:39:50 +08:00
default:
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
if (add_variable)
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
if (in_scope_only && !variable_sp->IsInScope(frame_sp.get()))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
continue;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
value_list.Append(frame_sp->GetValueObjectForFrameVariable (variable_sp, use_dynamic));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
}
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
log->Printf ("SBFrame(%p)::GetVariables (...) => SBValueList(%p)", frame_sp.get(),
Clean up the API logging code: - Try to reduce logging to one line per function call instead of tw - Put all arguments & their values into log for calls - Add 'this' parameter information to function call logging, making it show the appropriate internal pointer (this.obj, this.sp, this.ap...) - Clean up some return values - Remove logging of constructors that construct empty objects - Change '==>' to '=>' for showing result values... - Fix various minor bugs - Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments... llvm-svn: 117417
2010-10-27 07:49:36 +08:00
value_list.get());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return value_list;
}
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
SBValueList
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBFrame::GetRegisters ()
{
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBValueList value_list;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
RegisterContextSP reg_ctx (frame_sp->GetRegisterContext());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (reg_ctx)
{
const uint32_t num_sets = reg_ctx->GetRegisterSetCount();
for (uint32_t set_idx = 0; set_idx < num_sets; ++set_idx)
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
value_list.Append(ValueObjectRegisterSet::Create (frame_sp.get(), reg_ctx, set_idx));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
if (log)
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
log->Printf ("SBFrame(%p)::Registers () => SBValueList(%p)", frame_sp.get(), value_list.get());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return value_list;
}
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
bool
SBFrame::GetDescription (SBStream &description)
{
<rdar://problem/10126482> Fixed an issues with the SBType and SBTypeMember classes: - Fixed SBType to be able to dump itself from python - Fixed SBType::GetNumberOfFields() to return the correct value for objective C interfaces - Fixed SBTypeMember to be able to dump itself from python - Fixed the SBTypeMember ability to get a field offset in bytes (the value being returned was wrong) - Added the SBTypeMember ability to get a field offset in bits Cleaned up a lot of the Stream usage in the SB API files. llvm-svn: 144493
2011-11-13 14:57:31 +08:00
Stream &strm = description.ref();
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
frame_sp->DumpUsingSettingsFormat (&strm);
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
}
else
<rdar://problem/10126482> Fixed an issues with the SBType and SBTypeMember classes: - Fixed SBType to be able to dump itself from python - Fixed SBType::GetNumberOfFields() to return the correct value for objective C interfaces - Fixed SBTypeMember to be able to dump itself from python - Fixed the SBTypeMember ability to get a field offset in bytes (the value being returned was wrong) - Added the SBTypeMember ability to get a field offset in bits Cleaned up a lot of the Stream usage in the SB API files. llvm-svn: 144493
2011-11-13 14:57:31 +08:00
strm.PutCString ("No value");
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
return true;
}
Added a new ValueObject type that will be used to freeze dry expression results. The clang opaque type for the expression result will be added to the Target's ASTContext, and the bytes will be stored in a DataBuffer inside the new object. The class is named: ValueObjectConstResult Now after an expression is evaluated, we can get a ValueObjectSP back that contains a ValueObjectConstResult object. Relocated the value object dumping code into a static function within the ValueObject class instead of being in the CommandObjectFrame.cpp file which is what contained the code to dump variables ("frame variables"). llvm-svn: 115578
2010-10-05 08:00:42 +08:00
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
SBValue
Added a new ValueObject type that will be used to freeze dry expression results. The clang opaque type for the expression result will be added to the Target's ASTContext, and the bytes will be stored in a DataBuffer inside the new object. The class is named: ValueObjectConstResult Now after an expression is evaluated, we can get a ValueObjectSP back that contains a ValueObjectConstResult object. Relocated the value object dumping code into a static function within the ValueObject class instead of being in the CommandObjectFrame.cpp file which is what contained the code to dump variables ("frame variables"). llvm-svn: 115578
2010-10-05 08:00:42 +08:00
SBFrame::EvaluateExpression (const char *expr)
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
{
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
SBValue result;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
lldb::DynamicValueType use_dynamic = frame_sp->CalculateTarget()->GetPreferDynamicValue();
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
result = EvaluateExpression (expr, use_dynamic);
}
return result;
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
}
SBValue
Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay). Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target, and dynamic with running target. llvm-svn: 130832
2011-05-04 11:43:18 +08:00
SBFrame::EvaluateExpression (const char *expr, lldb::DynamicValueType fetch_dynamic_value)
Added a new ValueObject type that will be used to freeze dry expression results. The clang opaque type for the expression result will be added to the Target's ASTContext, and the bytes will be stored in a DataBuffer inside the new object. The class is named: ValueObjectConstResult Now after an expression is evaluated, we can get a ValueObjectSP back that contains a ValueObjectConstResult object. Relocated the value object dumping code into a static function within the ValueObject class instead of being in the CommandObjectFrame.cpp file which is what contained the code to dump variables ("frame variables"). llvm-svn: 115578
2010-10-05 08:00:42 +08:00
{
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
More logging for use in debugging the interactions between clients of the LLDB API and the expression parser. llvm-svn: 121193
2010-12-08 06:55:01 +08:00
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
LogSP expr_log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
Incremental fixes of issues found by Xcode static analyzer. llvm-svn: 137257
2011-08-11 06:06:24 +08:00
ExecutionResults exe_results;
Changed: SBValue SBFrame::LookupVar(const char *name); To SBValue SBFrame::FindVariable (const char *name); Changed: SBValue LookupVarInScope (const char *name, const char *scope); to SBValue FindValue (const char *name, ValueType value_type); The latter makes it possible to not only find variables (params, locals, globals, and statics), but we can also now get register sets, registers and persistent variables using the frame as the context. llvm-svn: 121777
2010-12-15 02:39:31 +08:00
SBValue expr_result;
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
ValueObjectSP expr_value_sp;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
log->Printf ("SBFrame(%p)::EvaluateExpression (expr=\"%s\")...", frame_sp.get(), expr);
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
if (frame_sp)
Added a new ValueObject type that will be used to freeze dry expression results. The clang opaque type for the expression result will be added to the Target's ASTContext, and the bytes will be stored in a DataBuffer inside the new object. The class is named: ValueObjectConstResult Now after an expression is evaluated, we can get a ValueObjectSP back that contains a ValueObjectConstResult object. Relocated the value object dumping code into a static function within the ValueObject class instead of being in the CommandObjectFrame.cpp file which is what contained the code to dump variables ("frame variables"). llvm-svn: 115578
2010-10-05 08:00:42 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Mutex::Locker api_locker (frame_sp->GetThread().GetProcess().GetTarget().GetAPIMutex());
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
Bumped Xcode project versions to lldb-65 and debugserver-140. llvm-svn: 133865
2011-06-25 12:35:01 +08:00
StreamString frame_description;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
frame_sp->DumpUsingSettingsFormat (&frame_description);
Bumped Xcode project versions to lldb-65 and debugserver-140. llvm-svn: 133865
2011-06-25 12:35:01 +08:00
Host::SetCrashDescriptionWithFormat ("SBFrame::EvaluateExpression (expr = \"%s\", fetch_dynamic_value = %u) %s",
expr, fetch_dynamic_value, frame_description.GetString().c_str());
The "desired result type" code in the expression parser has hitherto been an implementation waiting for a use. I have now tied the '-o' option for the expression command -- which indicates that the result is an Objective-C object and needs to be printed -- to the ExpressionParser, which communicates the desired type to Clang. Now, if the result of an expression is determined by an Objective-C method call for which there is no type information, that result is implicitly cast to id if and only if the -o option is passed to the expression command. (Otherwise if there is no explicit cast Clang will issue an error. This behavior is identical to what happened before r146756.) Also added a testcase for -o enabled and disabled. llvm-svn: 147099
2011-12-22 06:22:58 +08:00
const bool coerce_to_id = false;
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
const bool unwind_on_error = true;
Implemented a major overhaul of the way variables are handled by LLDB. Instead of being materialized into the input structure passed to the expression, variables are left in place and pointers to them are materialzied into the structure. Variables not resident in memory (notably, registers) get temporary memory regions allocated for them. Persistent variables are the most complex part of this, because they are made in various ways and there are different expectations about their lifetime. Persistent variables now have flags indicating their status and what the expectations for longevity are. They can be marked as residing in target memory permanently -- this is the default for result variables from expressions entered on the command line and for explicitly declared persistent variables (but more on that below). Other result variables have their memory freed. Some major improvements resulting from this include being able to properly take the address of variables, better and cleaner support for functions that return references, and cleaner C++ support in general. One problem that remains is the problem of explicitly declared persistent variables; I have not yet implemented the code that makes references to them into indirect references, so currently materialization and dematerialization of these variables is broken. llvm-svn: 123371
2011-01-13 16:53:35 +08:00
const bool keep_in_memory = false;
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
exe_results = frame_sp->GetThread().GetProcess().GetTarget().EvaluateExpression(expr,
frame_sp.get(),
eExecutionPolicyOnlyWhenNeeded,
coerce_to_id,
unwind_on_error,
keep_in_memory,
fetch_dynamic_value,
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
expr_value_sp);
expr_result.SetSP(expr_value_sp);
Made the Host::SetCrashDescription(const char *) function copy the incoming string to avoid possible later crashes. Modified the locations that do set the crash description to NULL out the string when they are done doing their tasks. llvm-svn: 144297
2011-11-11 02:31:53 +08:00
Host::SetCrashDescription (NULL);
Added a new ValueObject type that will be used to freeze dry expression results. The clang opaque type for the expression result will be added to the Target's ASTContext, and the bytes will be stored in a DataBuffer inside the new object. The class is named: ValueObjectConstResult Now after an expression is evaluated, we can get a ValueObjectSP back that contains a ValueObjectConstResult object. Relocated the value object dumping code into a static function within the ValueObject class instead of being in the CommandObjectFrame.cpp file which is what contained the code to dump variables ("frame variables"). llvm-svn: 115578
2010-10-05 08:00:42 +08:00
}
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
More logging for use in debugging the interactions between clients of the LLDB API and the expression parser. llvm-svn: 121193
2010-12-08 06:55:01 +08:00
if (expr_log)
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
expr_log->Printf("** [SBFrame::EvaluateExpression] Expression result is %s, summary %s **",
Cleaned up the SBType.h file to not include internal headers and reorganized the SBType implementation classes. Fixed LLDB core and the test suite to not use deprecated SBValue APIs. Added a few new APIs to SBValue: int64_t SBValue::GetValueAsSigned(int64_t fail_value=0); uint64_t SBValue::GetValueAsUnsigned(uint64_t fail_value=0) llvm-svn: 136829
2011-08-04 06:57:10 +08:00
expr_result.GetValue(),
expr_result.GetSummary());
More logging for use in debugging the interactions between clients of the LLDB API and the expression parser. llvm-svn: 121193
2010-12-08 06:55:01 +08:00
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
if (log)
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
log->Printf ("SBFrame(%p)::EvaluateExpression (expr=\"%s\") => SBValue(%p) (execution result=%d)", frame_sp.get(),
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
expr,
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
expr_value_sp.get(),
Incremental fixes of issues found by Xcode static analyzer. llvm-svn: 137257
2011-08-11 06:06:24 +08:00
exe_results);
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
Cleaned up the API logging a lot more to reduce redundant information and keep the file size a bit smaller. Exposed SBValue::GetExpressionPath() so SBValue users can get an expression path for their values. llvm-svn: 117851
2010-10-31 11:01:06 +08:00
return expr_result;
Added a new ValueObject type that will be used to freeze dry expression results. The clang opaque type for the expression result will be added to the Target's ASTContext, and the bytes will be stored in a DataBuffer inside the new object. The class is named: ValueObjectConstResult Now after an expression is evaluated, we can get a ValueObjectSP back that contains a ValueObjectConstResult object. Relocated the value object dumping code into a static function within the ValueObject class instead of being in the CommandObjectFrame.cpp file which is what contained the code to dump variables ("frame variables"). llvm-svn: 115578
2010-10-05 08:00:42 +08:00
}
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
bool
SBFrame::IsInlined()
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
Block *block = frame_sp->GetSymbolContext(eSymbolContextBlock).block;
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
if (block)
return block->GetContainingInlinedBlock () != NULL;
}
return false;
}
const char *
SBFrame::GetFunctionName()
{
const char *name = NULL;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
StackFrameSP frame_sp(GetFrameSP());
if (frame_sp)
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
{
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 15:41:31 +08:00
SymbolContext sc (frame_sp->GetSymbolContext(eSymbolContextFunction | eSymbolContextBlock | eSymbolContextSymbol));
Added two new API functions to SBFrame: const char * SBFrame::GetFunctionName(); bool SBFrame::IsInlined(); The first one will return the correct name for a frame. The name of a frame is: - the name of the inlined function (if there is one) - the name of the concrete function (if there is one) - the name of the symbol (if there is one) - NULL We also can now easily check if a frame is an inline function or not. llvm-svn: 133357
2011-06-19 04:06:08 +08:00
if (sc.block)
{
Block *inlined_block = sc.block->GetContainingInlinedBlock ();
if (inlined_block)
{
const InlineFunctionInfo* inlined_info = inlined_block->GetInlinedFunctionInfo();
name = inlined_info->GetName().AsCString();
}
}
if (name == NULL)
{
if (sc.function)
name = sc.function->GetName().GetCString();
}
if (name == NULL)
{
if (sc.symbol)
name = sc.symbol->GetName().GetCString();
}
}
return name;
}