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/SBModule.cpp

401 lines
9.4 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
//===-- SBModule.cpp --------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/API/SBModule.h"
Added some missing API for address resolving within a module, and looking up a seciton offset address (SBAddress) within a module that returns a symbol context (SBSymbolContext). Also added a SBSymbolContextList in preparation for adding find/lookup APIs that can return multiple results. Added a lookup example code that shows how to do address lookups. llvm-svn: 113599
2010-09-11 02:31:35 +08:00
#include "lldb/API/SBAddress.h"
#include "lldb/API/SBFileSpec.h"
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
#include "lldb/API/SBStream.h"
Added the ability to find functions from either a SBModule (find functions only in a specific module), or in a SBTarget (all modules for a target). llvm-svn: 133498
2011-06-21 09:34:41 +08:00
#include "lldb/API/SBSymbolContextList.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/Module.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"
Fixed an include so case sensitive builders can build. llvm-svn: 117864
2010-11-01 03:57:43 +08:00
#include "lldb/Core/StreamString.h"
Added support for finding and global variables in the SBTarget and SBModule level in the public API. Also modified the ValueObject values to be able to display global variables without having a valid running process. The globals will read themselves from the object file section data if there is no process, and from the process if there is one. Also fixed an issue where modifications for dynamic types could cause child values of ValueObjects to not show up if the value was unable to evaluate itself (children of NULL pointer objects). llvm-svn: 134102
2011-06-30 06:09:02 +08:00
#include "lldb/Core/ValueObjectList.h"
#include "lldb/Core/ValueObjectVariable.h"
Public API changes: - Completely new implementation of SBType - Various enhancements in several other classes Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>: - these return the actual elements into the container as the children of the container - basic template name parsing that works (hopefully) on both Clang and GCC - find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth New summary string token ${svar : - the syntax is just the same as in ${var but this new token lets you read the values coming from the synthetic children provider instead of the actual children - Python providers above provide a synthetic child len that returns the number of elements into the container Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB Several other fixes, including: - inverted the order of arguments in the ClangASTType constructor - EvaluationPoint now only returns SharedPointer's to Target and Process - the help text for several type subcommands now correctly indicates argument-less options as such llvm-svn: 136504
2011-07-30 03:53:35 +08:00
#include "lldb/Symbol/SymbolVendor.h"
Added support for finding and global variables in the SBTarget and SBModule level in the public API. Also modified the ValueObject values to be able to display global variables without having a valid running process. The globals will read themselves from the object file section data if there is no process, and from the process if there is one. Also fixed an issue where modifications for dynamic types could cause child values of ValueObjects to not show up if the value was unable to evaluate itself (children of NULL pointer objects). llvm-svn: 134102
2011-06-30 06:09:02 +08:00
#include "lldb/Symbol/VariableList.h"
#include "lldb/Target/Target.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
using namespace lldb;
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
using namespace lldb_private;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBModule::SBModule () :
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
{
}
SBModule::SBModule (const lldb::ModuleSP& module_sp) :
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 (module_sp)
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
SBModule::SBModule(const SBModule &rhs) :
m_opaque_sp (rhs.m_opaque_sp)
{
}
const SBModule &
SBModule::operator = (const SBModule &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
SBModule::~SBModule ()
{
}
bool
SBModule::IsValid () const
{
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
return m_opaque_sp.get() != NULL;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
SBFileSpec
SBModule::GetFileSpec () const
{
Modified all logging calls to hand out shared pointers to make sure we don't crash if we disable logging when some code already has a copy of the logger. Prior to this fix, logs were handed out as pointers and if they were held onto while a log got disabled, then it could cause a crash. Now all logs are handed out as shared pointers so this problem shouldn't happen anymore. We are also using our new shared pointers that put the shared pointer count and the object into the same allocation for a tad better performance. llvm-svn: 118319
2010-11-06 09:53:30 +08:00
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SBFileSpec file_spec;
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
if (m_opaque_sp)
file_spec.SetFileSpec(m_opaque_sp->GetFileSpec());
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)
{
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
log->Printf ("SBModule(%p)::GetFileSpec () => SBFileSpec(%p)",
m_opaque_sp.get(), file_spec.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 file_spec;
}
Added the ability to set the Platform path for a module through the SBModule interface. Added a quick way to set the platform though the SBDebugger interface. I will actually an a SBPlatform support soon, but for now this will do. ConnectionFileDescriptor can be passed a url formatted as: "fd://<fd>" where <fd> is a file descriptor in the current process. This is handy if you have services, deamons, or other tools that can spawn processes and give you a file handle. llvm-svn: 130565
2011-04-30 09:09:13 +08:00
lldb::SBFileSpec
SBModule::GetPlatformFileSpec () const
{
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
SBFileSpec file_spec;
if (m_opaque_sp)
file_spec.SetFileSpec(m_opaque_sp->GetPlatformFileSpec());
if (log)
{
log->Printf ("SBModule(%p)::GetPlatformFileSpec () => SBFileSpec(%p)",
m_opaque_sp.get(), file_spec.get());
}
return file_spec;
}
bool
SBModule::SetPlatformFileSpec (const lldb::SBFileSpec &platform_file)
{
bool result = false;
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
if (m_opaque_sp)
{
m_opaque_sp->SetPlatformFileSpec(*platform_file);
result = true;
}
if (log)
{
log->Printf ("SBModule(%p)::SetPlatformFileSpec (SBFileSpec(%p (%s%s%s)) => %i",
m_opaque_sp.get(),
platform_file.get(),
platform_file->GetDirectory().GetCString(),
platform_file->GetDirectory() ? "/" : "",
platform_file->GetFilename().GetCString(),
result);
}
return result;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const uint8_t *
SBModule::GetUUIDBytes () const
{
Modified all logging calls to hand out shared pointers to make sure we don't crash if we disable logging when some code already has a copy of the logger. Prior to this fix, logs were handed out as pointers and if they were held onto while a log got disabled, then it could cause a crash. Now all logs are handed out as shared pointers so this problem shouldn't happen anymore. We are also using our new shared pointers that put the shared pointer count and the object into the same allocation for a tad better performance. llvm-svn: 118319
2010-11-06 09:53:30 +08:00
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
const uint8_t *uuid_bytes = NULL;
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
if (m_opaque_sp)
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
uuid_bytes = (const uint8_t *)m_opaque_sp->GetUUID().GetBytes();
if (log)
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 (uuid_bytes)
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
StreamString s;
m_opaque_sp->GetUUID().Dump (&s);
log->Printf ("SBModule(%p)::GetUUIDBytes () => %s", m_opaque_sp.get(), s.GetData());
First pass at adding logging capabilities for the API functions. At the moment it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
2010-10-26 11:11:13 +08:00
}
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
else
log->Printf ("SBModule(%p)::GetUUIDBytes () => NULL", m_opaque_sp.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
}
Improved API logging. llvm-svn: 117772
2010-10-30 12:51:46 +08:00
return uuid_bytes;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Add TestSymbolAPI.py to test the newly added SBSymbol and SBAddress APIs: lldb::SymbolType SBSymbol::GetType(); lldb::SectionType SBAddress::GetSectionType (); lldb::SBModule SBAddress::GetModule (); Also add an lldb::SBModule::GetUUIDString() API which is easier for Python to work with in the test script. llvm-svn: 128695
2011-04-01 08:35:55 +08:00
const char *
SBModule::GetUUIDString () const
{
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
static char uuid_string[80];
const char * uuid_c_string = NULL;
if (m_opaque_sp)
uuid_c_string = (const char *)m_opaque_sp->GetUUID().GetAsCString(uuid_string, sizeof(uuid_string));
if (log)
{
if (uuid_c_string)
{
StreamString s;
m_opaque_sp->GetUUID().Dump (&s);
log->Printf ("SBModule(%p)::GetUUIDString () => %s", m_opaque_sp.get(), s.GetData());
}
else
log->Printf ("SBModule(%p)::GetUUIDString () => NULL", m_opaque_sp.get());
}
return uuid_c_string;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool
SBModule::operator == (const SBModule &rhs) const
{
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
if (m_opaque_sp)
return m_opaque_sp.get() == rhs.m_opaque_sp.get();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
}
bool
SBModule::operator != (const SBModule &rhs) const
{
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
if (m_opaque_sp)
return m_opaque_sp.get() != rhs.m_opaque_sp.get();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
}
lldb::ModuleSP &
SBModule::operator *()
{
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
return m_opaque_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
lldb_private::Module *
SBModule::operator ->()
{
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
return m_opaque_sp.get();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
const lldb_private::Module *
SBModule::operator ->() const
{
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
return m_opaque_sp.get();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
lldb_private::Module *
SBModule::get()
{
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
return m_opaque_sp.get();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
const lldb_private::Module *
SBModule::get() const
{
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
return m_opaque_sp.get();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
void
SBModule::SetModule (const lldb::ModuleSP& module_sp)
{
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 = module_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Added some missing API for address resolving within a module, and looking up a seciton offset address (SBAddress) within a module that returns a symbol context (SBSymbolContext). Also added a SBSymbolContextList in preparation for adding find/lookup APIs that can return multiple results. Added a lookup example code that shows how to do address lookups. llvm-svn: 113599
2010-09-11 02:31:35 +08:00
bool
SBModule::ResolveFileAddress (lldb::addr_t vm_addr, SBAddress& addr)
{
Add fuzz calls for SBModule and SBProcess. llvm-svn: 134037
2011-06-29 06:32:15 +08:00
if (m_opaque_sp && addr.IsValid())
Make the SBAddress class easier to use when using the public API. SBTarget changes include changing: bool SBTarget::ResolveLoadAddress (lldb::addr_t vm_addr, lldb::SBAddress& addr); to be: lldb::SBAddress SBTarget::ResolveLoadAddress (lldb::addr_t vm_addr); SBAddress can how contruct itself using a load address and a target which can be used to resolve the address: SBAddress (lldb::addr_t load_addr, lldb::SBTarget &target); This will actually just call the new SetLoadAddress accessor: void SetLoadAddress (lldb::addr_t load_addr, lldb::SBTarget &target); This function will always succeed in making a SBAddress object that can be used in API calls (even if "target" isn't valid). If "target" is valid and there are sections currently loaded, then it will resolve the address to a section offset address if it can. Else an address with a NULL section and an offset that is the "load_addr" that was passed in. We do this because a load address might be from the heap or stack. llvm-svn: 135770
2011-07-23 00:46:35 +08:00
return m_opaque_sp->ResolveFileAddress (vm_addr, addr.ref());
Added some missing API for address resolving within a module, and looking up a seciton offset address (SBAddress) within a module that returns a symbol context (SBSymbolContext). Also added a SBSymbolContextList in preparation for adding find/lookup APIs that can return multiple results. Added a lookup example code that shows how to do address lookups. llvm-svn: 113599
2010-09-11 02:31:35 +08:00
Add fuzz calls for SBModule and SBProcess. llvm-svn: 134037
2011-06-29 06:32:15 +08:00
if (addr.IsValid())
addr->Clear();
Added some missing API for address resolving within a module, and looking up a seciton offset address (SBAddress) within a module that returns a symbol context (SBSymbolContext). Also added a SBSymbolContextList in preparation for adding find/lookup APIs that can return multiple results. Added a lookup example code that shows how to do address lookups. llvm-svn: 113599
2010-09-11 02:31:35 +08:00
return false;
}
SBSymbolContext
SBModule::ResolveSymbolContextForAddress (const SBAddress& addr, uint32_t resolve_scope)
{
SBSymbolContext sb_sc;
if (m_opaque_sp && addr.IsValid())
Make the SBAddress class easier to use when using the public API. SBTarget changes include changing: bool SBTarget::ResolveLoadAddress (lldb::addr_t vm_addr, lldb::SBAddress& addr); to be: lldb::SBAddress SBTarget::ResolveLoadAddress (lldb::addr_t vm_addr); SBAddress can how contruct itself using a load address and a target which can be used to resolve the address: SBAddress (lldb::addr_t load_addr, lldb::SBTarget &target); This will actually just call the new SetLoadAddress accessor: void SetLoadAddress (lldb::addr_t load_addr, lldb::SBTarget &target); This function will always succeed in making a SBAddress object that can be used in API calls (even if "target" isn't valid). If "target" is valid and there are sections currently loaded, then it will resolve the address to a section offset address if it can. Else an address with a NULL section and an offset that is the "load_addr" that was passed in. We do this because a load address might be from the heap or stack. llvm-svn: 135770
2011-07-23 00:46:35 +08:00
m_opaque_sp->ResolveSymbolContextForAddress (addr.ref(), resolve_scope, *sb_sc);
Added some missing API for address resolving within a module, and looking up a seciton offset address (SBAddress) within a module that returns a symbol context (SBSymbolContext). Also added a SBSymbolContextList in preparation for adding find/lookup APIs that can return multiple results. Added a lookup example code that shows how to do address lookups. llvm-svn: 113599
2010-09-11 02:31:35 +08:00
return sb_sc;
}
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
SBModule::GetDescription (SBStream &description)
{
if (m_opaque_sp)
{
Remove all the __repr__ methods from the API/*.h files, and put them into python-extensions.swig, which gets included into lldb.swig, and adds them back into the classes when swig generates it's C++ file. This keeps the Python stuff out of the general API classes. Also fixed a small bug in the copy constructor for SBSymbolContext. llvm-svn: 114602
2010-09-23 07:01:29 +08:00
description.ref();
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
m_opaque_sp->GetDescription (description.get());
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
description.Printf ("No value");
return true;
}
Added symbol table access through the module for now. We might need to expose a SBSymtab class, but for now, we expose the symbols through the module. llvm-svn: 121112
2010-12-07 13:40:31 +08:00
size_t
SBModule::GetNumSymbols ()
{
if (m_opaque_sp)
{
ObjectFile *obj_file = m_opaque_sp->GetObjectFile();
if (obj_file)
{
Symtab *symtab = obj_file->GetSymtab();
if (symtab)
return symtab->GetNumSymbols();
}
}
return 0;
}
SBSymbol
SBModule::GetSymbolAtIndex (size_t idx)
{
SBSymbol sb_symbol;
if (m_opaque_sp)
{
ObjectFile *obj_file = m_opaque_sp->GetObjectFile();
if (obj_file)
{
Symtab *symtab = obj_file->GetSymtab();
if (symtab)
sb_symbol.SetSymbol(symtab->SymbolAtIndex (idx));
}
}
return sb_symbol;
}
Added the ability to find functions from either a SBModule (find functions only in a specific module), or in a SBTarget (all modules for a target). llvm-svn: 133498
2011-06-21 09:34:41 +08:00
uint32_t
SBModule::FindFunctions (const char *name,
uint32_t name_type_mask,
bool append,
lldb::SBSymbolContextList& sc_list)
{
if (!append)
sc_list.Clear();
if (m_opaque_sp)
{
const bool symbols_ok = true;
return m_opaque_sp->FindFunctions (ConstString(name),
name_type_mask,
symbols_ok,
append,
*sc_list);
}
return 0;
}
Added support for finding and global variables in the SBTarget and SBModule level in the public API. Also modified the ValueObject values to be able to display global variables without having a valid running process. The globals will read themselves from the object file section data if there is no process, and from the process if there is one. Also fixed an issue where modifications for dynamic types could cause child values of ValueObjects to not show up if the value was unable to evaluate itself (children of NULL pointer objects). llvm-svn: 134102
2011-06-30 06:09:02 +08:00
SBValueList
SBModule::FindGlobalVariables (SBTarget &target, const char *name, uint32_t max_matches)
{
SBValueList sb_value_list;
if (m_opaque_sp)
{
VariableList variable_list;
const uint32_t match_count = m_opaque_sp->FindGlobalVariables (ConstString (name),
false,
max_matches,
variable_list);
if (match_count > 0)
{
ValueObjectList &value_object_list = sb_value_list.ref();
for (uint32_t i=0; i<match_count; ++i)
{
lldb::ValueObjectSP valobj_sp;
if (target.IsValid())
valobj_sp = ValueObjectVariable::Create (target.get(), variable_list.GetVariableAtIndex(i));
else
valobj_sp = ValueObjectVariable::Create (NULL, variable_list.GetVariableAtIndex(i));
if (valobj_sp)
value_object_list.Append(valobj_sp);
}
}
}
return sb_value_list;
}
Public API changes: - Completely new implementation of SBType - Various enhancements in several other classes Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>: - these return the actual elements into the container as the children of the container - basic template name parsing that works (hopefully) on both Clang and GCC - find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth New summary string token ${svar : - the syntax is just the same as in ${var but this new token lets you read the values coming from the synthetic children provider instead of the actual children - Python providers above provide a synthetic child len that returns the number of elements into the container Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB Several other fixes, including: - inverted the order of arguments in the ClangASTType constructor - EvaluationPoint now only returns SharedPointer's to Target and Process - the help text for several type subcommands now correctly indicates argument-less options as such llvm-svn: 136504
2011-07-30 03:53:35 +08:00
lldb::SBType
SBModule::FindFirstType (const char* name_cstr)
{
if (!IsValid())
return lldb::SBType();
SymbolContext sc;
TypeList type_list;
uint32_t num_matches = 0;
ConstString name(name_cstr);
num_matches = m_opaque_sp->FindTypes(sc,
name,
false,
1,
type_list);
if (num_matches)
{
TypeSP type_sp (type_list.GetTypeAtIndex(0));
return lldb::SBType(type_sp);
}
else
return lldb::SBType();
}
lldb::SBTypeList
SBModule::FindTypes (const char* type)
{
SBTypeList retval;
if (!IsValid())
return retval;
SymbolContext sc;
TypeList type_list;
uint32_t num_matches = 0;
ConstString name(type);
num_matches = m_opaque_sp->FindTypes(sc,
name,
false,
UINT32_MAX,
type_list);
for (size_t idx = 0; idx < num_matches; idx++)
{
TypeSP sp_at_idx = type_list.GetTypeAtIndex(idx);
retval.AppendType(SBType(sp_at_idx));
}
return retval;
}