intel/llvm
1
0
Fork 0
mirror of https://github.com/intel/llvm.git synced 2026-01-15 20:54:40 +08:00
Code Issues Packages Projects Releases Wiki Activity
Files
6df8945f04fa332c37bd11387346a0bebcf62653
llvm/lldb/source/Interpreter/ScriptInterpreterPython.cpp

2735 lines
98 KiB
C++
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
//===-- ScriptInterpreterPython.cpp -----------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
// In order to guarantee correct working with Python, Python.h *MUST* be
Move Python.h includes out of the headers into the .cpp file where it's actually used. Python.h includes a ton of macros that can cause weird behavior down the road. llvm-svn: 142754
2011-10-23 16:49:03 +00:00
// the *FIRST* header file included here.
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 03:34:56 +00:00
#ifdef LLDB_DISABLE_PYTHON
// Python is disabled in this build
#else
Move Python.h includes out of the headers into the .cpp file where it's actually used. Python.h includes a ton of macros that can cause weird behavior down the road. llvm-svn: 142754
2011-10-23 16:49:03 +00:00
#if defined (__APPLE__)
#include <Python/Python.h>
#else
#include <Python.h>
#endif
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
#include "lldb/Interpreter/ScriptInterpreterPython.h"
#include <stdlib.h>
#include <stdio.h>
#include <string>
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-06 19:20:51 +00:00
#include "lldb/API/SBValue.h"
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 08:33:22 +00:00
#include "lldb/Breakpoint/BreakpointLocation.h"
Very large changes that were needed in order to allow multiple connections to the debugger from GUI windows. Previously there was one global debugger instance that could be accessed that had its own command interpreter and current state (current target/process/thread/frame). When a GUI debugger was attached, if it opened more than one window that each had a console window, there were issues where the last one to setup the global debugger object won and got control of the debugger. To avoid this we now create instances of the lldb_private::Debugger that each has its own state: - target list for targets the debugger instance owns - current process/thread/frame - its own command interpreter - its own input, output and error file handles to avoid conflicts - its own input reader stack So now clients should call: SBDebugger::Initialize(); // (static function) SBDebugger debugger (SBDebugger::Create()); // Use which ever file handles you wish debugger.SetErrorFileHandle (stderr, false); debugger.SetOutputFileHandle (stdout, false); debugger.SetInputFileHandle (stdin, true); // main loop SBDebugger::Terminate(); // (static function) SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to ensure nothing gets destroyed too early when multiple clients might be attached. Cleaned up the command interpreter and the CommandObject and all subclasses to take more appropriate arguments. llvm-svn: 106615
2010-06-23 01:19:29 +00:00
#include "lldb/Breakpoint/StoppointCallbackContext.h"
rdar://problem/11457143 [ER] need "watchpoint command ..." Add 'watchpoint command add/delete/list' to lldb, plus two .py test files. llvm-svn: 161638
2012-08-09 23:09:42 +00:00
#include "lldb/Breakpoint/WatchpointOptions.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
#include "lldb/Core/Debugger.h"
#include "lldb/Core/Timer.h"
#include "lldb/Host/Host.h"
#include "lldb/Interpreter/CommandInterpreter.h"
#include "lldb/Interpreter/CommandReturnObject.h"
More SWIG cleanup. Moved the breakpoint callback function back to the ScriptInterpreterPython class and made a simple callback function that ScriptInterpreterPython::BreakpointCallbackFunction() now calls so we don't include any internal API stuff into the cpp file that is generated by SWIG. Fixed a few build warnings in debugserver. llvm-svn: 115926
2010-10-07 17:14:24 +00:00
#include "lldb/Target/Thread.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
using namespace lldb;
using namespace lldb_private;
Abtracted the innards of lldb-core away from the SB interface. There was some overlap in the SWIG integration which has now been fixed by introducing callbacks for initializing SWIG for each language (python only right now). There was also a breakpoint command callback that called into SWIG which has been abtracted into a callback to avoid cross over as well. Added a new binary: lldb-platform This will be the start of the remote platform that will use as much of the Host functionality to do its job so it should just work on all platforms. It is pretty hollowed out for now, but soon it will implement a platform using the GDB remote packets as the transport. llvm-svn: 128053
2011-03-22 01:14:58 +00:00
static ScriptInterpreter::SWIGInitCallback g_swig_init_callback = NULL;
static ScriptInterpreter::SWIGBreakpointCallbackFunction g_swig_breakpoint_callback = NULL;
rdar://problem/11457143 [ER] need "watchpoint command ..." Add 'watchpoint command add/delete/list' to lldb, plus two .py test files. llvm-svn: 161638
2012-08-09 23:09:42 +00:00
static ScriptInterpreter::SWIGWatchpointCallbackFunction g_swig_watchpoint_callback = NULL;
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
static ScriptInterpreter::SWIGPythonTypeScriptCallbackFunction g_swig_typescript_callback = NULL;
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
static ScriptInterpreter::SWIGPythonCreateSyntheticProvider g_swig_synthetic_script = NULL;
static ScriptInterpreter::SWIGPythonCalculateNumChildren g_swig_calc_children = NULL;
static ScriptInterpreter::SWIGPythonGetChildAtIndex g_swig_get_child_index = NULL;
static ScriptInterpreter::SWIGPythonGetIndexOfChildWithName g_swig_get_index_child = NULL;
static ScriptInterpreter::SWIGPythonCastPyObjectToSBValue g_swig_cast_to_sbvalue = NULL;
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-29 19:53:35 +00:00
static ScriptInterpreter::SWIGPythonUpdateSynthProviderInstance g_swig_update_provider = NULL;
<rdar://problem/12523238> Commit 1 of 3 This commit enables the new HasChildren() feature for synthetic children providers Namely, it hooks up the required bits and pieces so that individual synthetic children providers can implement a new (optional) has_children call Default implementations have been provided where necessary so that any existing providers continue to work and behave correctly Next steps are: 2) writing smart implementations of has_children for our providers whenever possible 3) make a test case llvm-svn: 166495
2012-10-23 19:54:09 +00:00
static ScriptInterpreter::SWIGPythonMightHaveChildrenSynthProviderInstance g_swig_mighthavechildren_provider = NULL;
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
static ScriptInterpreter::SWIGPythonCallCommand g_swig_call_command = NULL;
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
static ScriptInterpreter::SWIGPythonCallModuleInit g_swig_call_module_init = NULL;
Adding bindings to the Script Interpreter for some basic Python OS plugin functionality (still WIP) llvm-svn: 162513
2012-08-24 00:30:47 +00:00
static ScriptInterpreter::SWIGPythonCreateOSPlugin g_swig_create_os_plugin = NULL;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
This commit: a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
2012-02-29 03:28:49 +00:00
// these are the Pythonic implementations of the required callbacks
// these are scripting-language specific, which is why they belong here
// we still need to use function pointers to them instead of relying
// on linkage-time resolution because the SWIG stuff and this file
// get built at different times
extern "C" bool
LLDBSwigPythonBreakpointCallbackFunction
(
const char *python_function_name,
const char *session_dictionary_name,
const lldb::StackFrameSP& sb_frame,
const lldb::BreakpointLocationSP& sb_bp_loc
);
rdar://problem/11457143 [ER] need "watchpoint command ..." Add 'watchpoint command add/delete/list' to lldb, plus two .py test files. llvm-svn: 161638
2012-08-09 23:09:42 +00:00
extern "C" bool
LLDBSwigPythonWatchpointCallbackFunction
(
const char *python_function_name,
const char *session_dictionary_name,
const lldb::StackFrameSP& sb_frame,
const lldb::WatchpointSP& sb_wp
);
This commit: a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
2012-02-29 03:28:49 +00:00
extern "C" bool
LLDBSwigPythonCallTypeScript
(
const char *python_function_name,
void *session_dictionary,
const lldb::ValueObjectSP& valobj_sp,
void** pyfunct_wrapper,
std::string& retval
);
extern "C" void*
LLDBSwigPythonCreateSyntheticProvider
(
const std::string python_class_name,
const char *session_dictionary_name,
const lldb::ValueObjectSP& valobj_sp
);
<rdar://problem/12523238> Commit 1 of 3 This commit enables the new HasChildren() feature for synthetic children providers Namely, it hooks up the required bits and pieces so that individual synthetic children providers can implement a new (optional) has_children call Default implementations have been provided where necessary so that any existing providers continue to work and behave correctly Next steps are: 2) writing smart implementations of has_children for our providers whenever possible 3) make a test case llvm-svn: 166495
2012-10-23 19:54:09 +00:00
extern "C" uint32_t LLDBSwigPython_CalculateNumChildren (void *implementor);
extern "C" void* LLDBSwigPython_GetChildAtIndex (void *implementor, uint32_t idx);
extern "C" int LLDBSwigPython_GetIndexOfChildWithName (void *implementor, const char* child_name);
extern "C" void* LLDBSWIGPython_CastPyObjectToSBValue (void* data);
extern "C" bool LLDBSwigPython_UpdateSynthProviderInstance (void* implementor);
extern "C" bool LLDBSwigPython_MightHaveChildrenSynthProviderInstance (void* implementor);
This commit: a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
2012-02-29 03:28:49 +00:00
extern "C" bool LLDBSwigPythonCallCommand
(
const char *python_function_name,
const char *session_dictionary_name,
lldb::DebuggerSP& debugger,
const char* args,
std::string& err_msg,
lldb_private::CommandReturnObject& cmd_retobj
);
extern "C" bool LLDBSwigPythonCallModuleInit
(
const std::string python_module_name,
const char *session_dictionary_name,
lldb::DebuggerSP& debugger
);
Adding bindings to the Script Interpreter for some basic Python OS plugin functionality (still WIP) llvm-svn: 162513
2012-08-24 00:30:47 +00:00
extern "C" void* LLDBSWIGPythonCreateOSPlugin
(
const std::string python_class_name,
const char *session_dictionary_name,
const lldb::ProcessSP& process_sp
);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
static int
_check_and_flush (FILE *stream)
{
int prev_fail = ferror (stream);
return fflush (stream) || prev_fail ? EOF : 0;
}
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
ScriptInterpreterPython::Locker::Locker (ScriptInterpreterPython *py_interpreter,
uint16_t on_entry,
uint16_t on_leave,
FILE* wait_msg_handle) :
m_need_session( (on_leave & TearDownSession) == TearDownSession ),
m_python_interpreter(py_interpreter),
m_tmp_fh(wait_msg_handle)
{
if (m_python_interpreter && !m_tmp_fh)
m_tmp_fh = (m_python_interpreter->m_dbg_stdout ? m_python_interpreter->m_dbg_stdout : stdout);
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
DoAcquireLock();
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
if ( (on_entry & InitSession) == InitSession )
DoInitSession();
}
bool
ScriptInterpreterPython::Locker::DoAcquireLock()
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-06 19:20:51 +00:00
{
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
LogSP log (lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_SCRIPT | LIBLLDB_LOG_VERBOSE));
m_GILState = PyGILState_Ensure();
if (log)
log->Printf("Ensured PyGILState. Previous state = %slocked\n", m_GILState == PyGILState_UNLOCKED ? "un" : "");
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
return true;
}
bool
ScriptInterpreterPython::Locker::DoInitSession()
{
if (!m_python_interpreter)
return false;
m_python_interpreter->EnterSession ();
return true;
}
bool
ScriptInterpreterPython::Locker::DoFreeLock()
{
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
LogSP log (lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_SCRIPT | LIBLLDB_LOG_VERBOSE));
if (log)
log->Printf("Releasing PyGILState. Returning to state = %slocked\n", m_GILState == PyGILState_UNLOCKED ? "un" : "");
PyGILState_Release(m_GILState);
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
return true;
}
bool
ScriptInterpreterPython::Locker::DoTearDownSession()
{
if (!m_python_interpreter)
return false;
m_python_interpreter->LeaveSession ();
return true;
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-06 19:20:51 +00:00
}
ScriptInterpreterPython::Locker::~Locker()
{
if (m_need_session)
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
DoTearDownSession();
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
DoFreeLock();
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-06 19:20:51 +00:00
}
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
ScriptInterpreterPython::PythonInputReaderManager::PythonInputReaderManager (ScriptInterpreterPython *interpreter) :
m_interpreter(interpreter),
m_debugger_sp(),
m_reader_sp(),
m_error(false)
{
if (m_interpreter == NULL)
{
m_error = true;
return;
}
m_debugger_sp = m_interpreter->GetCommandInterpreter().GetDebugger().shared_from_this();
if (!m_debugger_sp)
{
m_error = true;
return;
}
m_reader_sp = InputReaderSP(new InputReader(*m_debugger_sp.get()));
if (!m_reader_sp)
{
m_error = true;
return;
}
Error error (m_reader_sp->Initialize (ScriptInterpreterPython::PythonInputReaderManager::InputReaderCallback,
m_interpreter, // baton
eInputReaderGranularityLine, // token size, to pass to callback function
NULL, // end token
NULL, // prompt
true)); // echo input
if (error.Fail())
m_error = true;
else
{
m_debugger_sp->PushInputReader (m_reader_sp);
m_interpreter->m_embedded_thread_input_reader_sp = m_reader_sp;
}
}
ScriptInterpreterPython::PythonInputReaderManager::~PythonInputReaderManager()
{
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
// Nothing to do if either m_interpreter or m_reader_sp is invalid.
if (!m_interpreter || !m_reader_sp)
return;
m_reader_sp->SetIsDone (true);
if (m_debugger_sp)
m_debugger_sp->PopInputReader(m_reader_sp);
// Only mess with m_interpreter's counterpart if, indeed, they are the same object.
if (m_reader_sp.get() == m_interpreter->m_embedded_thread_input_reader_sp.get())
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
{
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
m_interpreter->m_embedded_thread_pty.CloseSlaveFileDescriptor();
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
m_interpreter->m_embedded_thread_input_reader_sp.reset();
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
}
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
}
size_t
ScriptInterpreterPython::PythonInputReaderManager::InputReaderCallback
(
void *baton,
InputReader &reader,
InputReaderAction notification,
const char *bytes,
size_t bytes_len
)
{
lldb::thread_t embedded_interpreter_thread;
LogSP log (lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_SCRIPT));
if (baton == NULL)
return 0;
ScriptInterpreterPython *script_interpreter = (ScriptInterpreterPython *) baton;
if (script_interpreter->m_script_lang != eScriptLanguagePython)
return 0;
StreamSP out_stream = reader.GetDebugger().GetAsyncOutputStream();
switch (notification)
{
case eInputReaderActivate:
{
// Save terminal settings if we can
int input_fd = reader.GetDebugger().GetInputFile().GetDescriptor();
if (input_fd == File::kInvalidDescriptor)
input_fd = STDIN_FILENO;
script_interpreter->SaveTerminalState(input_fd);
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
char error_str[1024];
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
if (script_interpreter->m_embedded_thread_pty.OpenFirstAvailableMaster (O_RDWR|O_NOCTTY, error_str,
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
sizeof(error_str)))
{
if (log)
log->Printf ("ScriptInterpreterPython::NonInteractiveInputReaderCallback, Activate, succeeded in opening master pty (fd = %d).",
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
script_interpreter->m_embedded_thread_pty.GetMasterFileDescriptor());
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
{
StreamString run_string;
char error_str[1024];
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
const char *pty_slave_name = script_interpreter->m_embedded_thread_pty.GetSlaveName (error_str, sizeof (error_str));
<rdar://problem/11862570> Fixing a potential crasher related to Python locking llvm-svn: 161054
2012-07-31 16:58:12 +00:00
if (pty_slave_name != NULL && PyThreadState_GetDict() != NULL)
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
{
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
ScriptInterpreterPython::Locker locker(script_interpreter,
ScriptInterpreterPython::Locker::AcquireLock | ScriptInterpreterPython::Locker::InitSession,
ScriptInterpreterPython::Locker::FreeAcquiredLock);
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
run_string.Printf ("run_one_line (%s, 'save_stderr = sys.stderr')", script_interpreter->m_dictionary_name.c_str());
PyRun_SimpleString (run_string.GetData());
run_string.Clear ();
run_string.Printf ("run_one_line (%s, 'sys.stderr = sys.stdout')", script_interpreter->m_dictionary_name.c_str());
PyRun_SimpleString (run_string.GetData());
run_string.Clear ();
run_string.Printf ("run_one_line (%s, 'save_stdin = sys.stdin')", script_interpreter->m_dictionary_name.c_str());
PyRun_SimpleString (run_string.GetData());
run_string.Clear ();
run_string.Printf ("run_one_line (%s, \"sys.stdin = open ('%s', 'r')\")", script_interpreter->m_dictionary_name.c_str(),
pty_slave_name);
PyRun_SimpleString (run_string.GetData());
run_string.Clear ();
}
}
embedded_interpreter_thread = Host::ThreadCreate ("<lldb.script-interpreter.noninteractive-python>",
ScriptInterpreterPython::PythonInputReaderManager::RunPythonInputReader,
script_interpreter, NULL);
if (IS_VALID_LLDB_HOST_THREAD(embedded_interpreter_thread))
{
if (log)
log->Printf ("ScriptInterpreterPython::NonInteractiveInputReaderCallback, Activate, succeeded in creating thread (thread_t = %p)", embedded_interpreter_thread);
Error detach_error;
Host::ThreadDetach (embedded_interpreter_thread, &detach_error);
}
else
{
if (log)
log->Printf ("ScriptInterpreterPython::NonInteractiveInputReaderCallback, Activate, failed in creating thread");
reader.SetIsDone (true);
}
}
else
{
if (log)
log->Printf ("ScriptInterpreterPython::NonInteractiveInputReaderCallback, Activate, failed to open master pty ");
reader.SetIsDone (true);
}
}
break;
case eInputReaderDeactivate:
// When another input reader is pushed, don't leave the session...
//script_interpreter->LeaveSession ();
break;
case eInputReaderReactivate:
Made it so changes to the prompt via "settings set prompt" get noticed by the command line. Added the ability for OptionValueString objects to take flags. The only flag is currently for parsing escape sequences. Not the prompt string can have escape characters translate which will allow colors in the prompt. Added functions to Args that will parse the escape sequences in a string, and also re-encode the escape sequences for display. This was looted from other parts of LLDB (the Debugger::FormatString() function). llvm-svn: 163043
2012-09-01 00:38:36 +00:00
// {
// ScriptInterpreterPython::Locker locker(script_interpreter,
// ScriptInterpreterPython::Locker::AcquireLock | ScriptInterpreterPython::Locker::InitSession,
// ScriptInterpreterPython::Locker::FreeAcquiredLock);
// }
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
break;
case eInputReaderAsynchronousOutputWritten:
break;
case eInputReaderInterrupt:
reader.SetIsDone(true);
break;
case eInputReaderEndOfFile:
reader.SetIsDone(true);
break;
case eInputReaderGotToken:
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
if (script_interpreter->m_embedded_thread_pty.GetMasterFileDescriptor() != -1)
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
{
if (log)
log->Printf ("ScriptInterpreterPython::NonInteractiveInputReaderCallback, GotToken, bytes='%s', byte_len = %lu", bytes,
bytes_len);
if (bytes && bytes_len)
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
::write (script_interpreter->m_embedded_thread_pty.GetMasterFileDescriptor(), bytes, bytes_len);
::write (script_interpreter->m_embedded_thread_pty.GetMasterFileDescriptor(), "\n", 1);
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
}
else
{
if (log)
log->Printf ("ScriptInterpreterPython::NonInteractiveInputReaderCallback, GotToken, bytes='%s', byte_len = %lu, Master File Descriptor is bad.",
bytes,
bytes_len);
reader.SetIsDone (true);
}
break;
case eInputReaderDone:
{
StreamString run_string;
char error_str[1024];
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
const char *pty_slave_name = script_interpreter->m_embedded_thread_pty.GetSlaveName (error_str, sizeof (error_str));
<rdar://problem/11862570> Fixing a potential crasher related to Python locking llvm-svn: 161054
2012-07-31 16:58:12 +00:00
if (pty_slave_name != NULL && PyThreadState_GetDict() != NULL)
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
{
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
ScriptInterpreterPython::Locker locker(script_interpreter,
ScriptInterpreterPython::Locker::AcquireLock | ScriptInterpreterPython::Locker::InitSession,
ScriptInterpreterPython::Locker::FreeAcquiredLock);
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
run_string.Printf ("run_one_line (%s, 'sys.stdin = save_stdin')", script_interpreter->m_dictionary_name.c_str());
PyRun_SimpleString (run_string.GetData());
run_string.Clear();
run_string.Printf ("run_one_line (%s, 'sys.stderr = save_stderr')", script_interpreter->m_dictionary_name.c_str());
PyRun_SimpleString (run_string.GetData());
run_string.Clear();
}
}
// Restore terminal settings if they were validly saved
if (log)
log->Printf ("ScriptInterpreterPython::NonInteractiveInputReaderCallback, Done, closing down input reader.");
script_interpreter->RestoreTerminalState ();
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
script_interpreter->m_embedded_thread_pty.CloseMasterFileDescriptor();
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
break;
}
return bytes_len;
}
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 01:19:29 +00:00
ScriptInterpreterPython::ScriptInterpreterPython (CommandInterpreter &interpreter) :
Fixed the way set/show variables were being accessed to being natively accessed by the objects that own the settings. The previous approach wasn't very usable and made for a lot of unnecessary code just to access variables that were already owned by the objects. While I fixed those things, I saw that CommandObject objects should really have a reference to their command interpreter so they can access the terminal with if they want to output usaage. Fixed up all CommandObjects to take an interpreter and cleaned up the API to not need the interpreter to be passed in. Fixed the disassemble command to output the usage if no options are passed down and arguments are passed (all disassebmle variants take options, there are no "args only"). llvm-svn: 114252
2010-09-18 01:14:36 +00:00
ScriptInterpreter (interpreter, eScriptLanguagePython),
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
m_embedded_thread_pty (),
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
m_embedded_python_pty (),
m_embedded_thread_input_reader_sp (),
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
m_embedded_python_input_reader_sp (),
Use Host::File in lldb_private::StreamFile and other places to cleanup host layer a bit more. llvm-svn: 125149
2011-02-09 01:08:52 +00:00
m_dbg_stdout (interpreter.GetDebugger().GetOutputFile().GetStream()),
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
m_new_sysout (NULL),
Fixed a crasher when Xcode calls into ScriptInterpreterPython::ResetOutputFileHandle(). The Locker should only perform acquire/free lock operation, but no enter/leave session at all. Also added sanity checks for items passed to the PyDict_SetItemString() calls. llvm-svn: 152337
2012-03-08 20:53:04 +00:00
m_old_sysout (NULL),
m_old_syserr (NULL),
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
m_run_one_line (NULL),
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
m_dictionary_name (interpreter.GetDebugger().GetInstanceName().AsCString()),
Abtract terminal stuff into a new lldb_private::Terminal class where the implementation is hidden in the host layer. This avoids a slew of "#if LLDB_CONFIG_TERMIOS_SUPPORTED" statements in the code and keeps things cleaner. llvm-svn: 125057
2011-02-07 23:24:47 +00:00
m_terminal_state (),
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
m_session_is_active (false),
m_valid_session (true)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Added support for some new environment variables within LLDB to enable some extra launch options: LLDB_LAUNCH_FLAG_DISABLE_ASLR disables ASLR for all launched processes LLDB_LAUNCH_FLAG_DISABLE_STDIO will disable STDIO (reroute to "/dev/null") for all launched processes LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY will force all launched processes to be launched in new terminal windows. Also, don't init python if we never create a script interpreter. llvm-svn: 124341
2011-01-27 01:01:10 +00:00
static int g_initialized = false;
if (!g_initialized)
{
g_initialized = true;
Abtracted the innards of lldb-core away from the SB interface. There was some overlap in the SWIG integration which has now been fixed by introducing callbacks for initializing SWIG for each language (python only right now). There was also a breakpoint command callback that called into SWIG which has been abtracted into a callback to avoid cross over as well. Added a new binary: lldb-platform This will be the start of the remote platform that will use as much of the Host functionality to do its job so it should just work on all platforms. It is pretty hollowed out for now, but soon it will implement a platform using the GDB remote packets as the transport. llvm-svn: 128053
2011-03-22 01:14:58 +00:00
ScriptInterpreterPython::InitializePrivate ();
Added support for some new environment variables within LLDB to enable some extra launch options: LLDB_LAUNCH_FLAG_DISABLE_ASLR disables ASLR for all launched processes LLDB_LAUNCH_FLAG_DISABLE_STDIO will disable STDIO (reroute to "/dev/null") for all launched processes LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY will force all launched processes to be launched in new terminal windows. Also, don't init python if we never create a script interpreter. llvm-svn: 124341
2011-01-27 01:01:10 +00:00
}
Replace Mutex guarding python interpreter access with Predicate, allowing timeouts & informing the user when the lock is unavailable. Fixed problem where Debugger::Terminate was clearing the debugger list even when the global ref count was greater than zero. llvm-svn: 123674
2011-01-17 21:55:19 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
m_dictionary_name.append("_dict");
StreamString run_string;
run_string.Printf ("%s = dict()", m_dictionary_name.c_str());
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
Locker locker(this,
ScriptInterpreterPython::Locker::AcquireLock,
ScriptInterpreterPython::Locker::FreeAcquiredLock);
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
PyRun_SimpleString (run_string.GetData());
run_string.Clear();
// Importing 'lldb' module calls SBDebugger::Initialize, which calls Debugger::Initialize, which increments a
// global debugger ref-count; therefore we need to check the ref-count before and after importing lldb, and if the
// ref-count increased we need to call Debugger::Terminate here to decrement the ref-count so that when the final
// call to Debugger::Terminate is made, the ref-count has the correct value.
//
// Bonus question: Why doesn't the ref-count always increase? Because sometimes lldb has already been imported, in
// which case the code inside it, including the call to SBDebugger::Initialize(), does not get executed.
int old_count = Debugger::TestDebuggerRefCount();
Added many more python convenience accessors: You can now access a frame in a thread using: lldb.SBThread.frame[int] -> lldb.SBFrame object for a frame in a thread Where "int" is an integer index. You can also access a list object with all of the frames using: lldb.SBThread.frames => list() of lldb.SBFrame objects All SB objects that give out SBAddress objects have properties named "addr" lldb.SBInstructionList now has the following convenience accessors for len() and instruction access using an index: insts = lldb.frame.function.instructions for idx in range(len(insts)): print insts[idx] Instruction lists can also lookup an isntruction using a lldb.SBAddress as the key: pc_inst = lldb.frame.function.instructions[lldb.frame.addr] lldb.SBProcess now exposes: lldb.SBProcess.is_alive => BOOL Check if a process is exists and is alive lldb.SBProcess.is_running => BOOL check if a process is running (or stepping): lldb.SBProcess.is_running => BOOL check if a process is currently stopped or crashed: lldb.SBProcess.thread[int] => lldb.SBThreads for a given "int" zero based index lldb.SBProcess.threads => list() containing all lldb.SBThread objects in a process SBInstruction now exposes: lldb.SBInstruction.mnemonic => python string for instruction mnemonic lldb.SBInstruction.operands => python string for instruction operands lldb.SBInstruction.command => python string for instruction comment SBModule now exposes: lldb.SBModule.uuid => uuid.UUID(), an UUID object from the "uuid" python module lldb.SBModule.symbol[int] => lldb.Symbol, lookup symbol by zero based index lldb.SBModule.symbol[str] => list() of lldb.Symbol objects that match "str" lldb.SBModule.symbol[re] => list() of lldb.Symbol objecxts that match the regex lldb.SBModule.symbols => list() of all symbols in a module SBAddress objects can now access the current load address with the "lldb.SBAddress.load_addr" property. The current "lldb.target" will be used to try and resolve the load address. Load addresses can also be set using this accessor: addr = lldb.SBAddress() addd.load_addr = 0x123023 Then you can check the section and offset to see if the address got resolved. SBTarget now exposes: lldb.SBTarget.module[int] => lldb.SBModule from zero based module index lldb.SBTarget.module[str] => lldb.SBModule by basename or fullpath or uuid string lldb.SBTarget.module[uuid.UUID()] => lldb.SBModule whose UUID matches lldb.SBTarget.module[re] => list() of lldb.SBModule objects that match the regex lldb.SBTarget.modules => list() of all lldb.SBModule objects in the target SBSymbol now exposes: lldb.SBSymbol.name => python string for demangled symbol name lldb.SBSymbol.mangled => python string for mangled symbol name or None if there is none lldb.SBSymbol.type => lldb.eSymbolType enum value lldb.SBSymbol.addr => SBAddress object that represents the start address for this symbol (if there is one) lldb.SBSymbol.end_addr => SBAddress for the end address of the symbol (if there is one) lldb.SBSymbol.prologue_size => pythin int containing The size of the prologue in bytes lldb.SBSymbol.instructions => SBInstructionList containing all instructions for this symbol SBFunction now also has these new properties in addition to what is already has: lldb.SBFunction.addr => SBAddress object that represents the start address for this function lldb.SBFunction.end_addr => SBAddress for the end address of the function lldb.SBFunction.instructions => SBInstructionList containing all instructions for this function SBFrame now exposes the SBAddress for the frame: lldb.SBFrame.addr => SBAddress which is the section offset address for the current frame PC These are all in addition to what was already added. Documentation and website updates coming soon. llvm-svn: 149489
2012-02-01 08:09:32 +00:00
Maked LLDB into a package so we can import things without poluting the global namespace. Enrico will follow this up with fixing the data formatter test cases that are failing. llvm-svn: 155514
2012-04-25 00:58:03 +00:00
run_string.Printf ("run_one_line (%s, 'import copy, os, re, sys, uuid, lldb')", m_dictionary_name.c_str());
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
PyRun_SimpleString (run_string.GetData());
Prevent Python script interpreter initialization from changing the termios settings on the debugger's input handle. llvm-svn: 116725
2010-10-18 18:24:17 +00:00
This patch provides a set of formatters for most of the commonly used Cocoa classes. The formatter for NSString is an improved version of the one previously shipped as an example, the others are new in design and implementation. A more robust and OO-compliant Objective-C runtime wrapper is provided for runtime versions 1 and 2 on 32 and 64 bit. The formatters are contained in a category named "AppKit", which is not enabled at startup. llvm-svn: 151299
2012-02-23 23:10:03 +00:00
// WARNING: temporary code that loads Cocoa formatters - this should be done on a per-platform basis rather than loading the whole set
// and letting the individual formatter classes exploit APIs to check whether they can/cannot do their task
run_string.Clear();
<rdar://problem/12479701> Use the plain pydoc pager to work around Python help() pagination conflicts with our I/O management llvm-svn: 166432
2012-10-22 19:09:28 +00:00
run_string.Printf ("run_one_line (%s, 'import lldb.runtime.objc, lldb.formatters, lldb.formatters.objc, lldb.formatters.cpp, pydoc')", m_dictionary_name.c_str());
This patch provides a set of formatters for most of the commonly used Cocoa classes. The formatter for NSString is an improved version of the one previously shipped as an example, the others are new in design and implementation. A more robust and OO-compliant Objective-C runtime wrapper is provided for runtime versions 1 and 2 on 32 and 64 bit. The formatters are contained in a category named "AppKit", which is not enabled at startup. llvm-svn: 151299
2012-02-23 23:10:03 +00:00
PyRun_SimpleString (run_string.GetData());
Added many more python convenience accessors: You can now access a frame in a thread using: lldb.SBThread.frame[int] -> lldb.SBFrame object for a frame in a thread Where "int" is an integer index. You can also access a list object with all of the frames using: lldb.SBThread.frames => list() of lldb.SBFrame objects All SB objects that give out SBAddress objects have properties named "addr" lldb.SBInstructionList now has the following convenience accessors for len() and instruction access using an index: insts = lldb.frame.function.instructions for idx in range(len(insts)): print insts[idx] Instruction lists can also lookup an isntruction using a lldb.SBAddress as the key: pc_inst = lldb.frame.function.instructions[lldb.frame.addr] lldb.SBProcess now exposes: lldb.SBProcess.is_alive => BOOL Check if a process is exists and is alive lldb.SBProcess.is_running => BOOL check if a process is running (or stepping): lldb.SBProcess.is_running => BOOL check if a process is currently stopped or crashed: lldb.SBProcess.thread[int] => lldb.SBThreads for a given "int" zero based index lldb.SBProcess.threads => list() containing all lldb.SBThread objects in a process SBInstruction now exposes: lldb.SBInstruction.mnemonic => python string for instruction mnemonic lldb.SBInstruction.operands => python string for instruction operands lldb.SBInstruction.command => python string for instruction comment SBModule now exposes: lldb.SBModule.uuid => uuid.UUID(), an UUID object from the "uuid" python module lldb.SBModule.symbol[int] => lldb.Symbol, lookup symbol by zero based index lldb.SBModule.symbol[str] => list() of lldb.Symbol objects that match "str" lldb.SBModule.symbol[re] => list() of lldb.Symbol objecxts that match the regex lldb.SBModule.symbols => list() of all symbols in a module SBAddress objects can now access the current load address with the "lldb.SBAddress.load_addr" property. The current "lldb.target" will be used to try and resolve the load address. Load addresses can also be set using this accessor: addr = lldb.SBAddress() addd.load_addr = 0x123023 Then you can check the section and offset to see if the address got resolved. SBTarget now exposes: lldb.SBTarget.module[int] => lldb.SBModule from zero based module index lldb.SBTarget.module[str] => lldb.SBModule by basename or fullpath or uuid string lldb.SBTarget.module[uuid.UUID()] => lldb.SBModule whose UUID matches lldb.SBTarget.module[re] => list() of lldb.SBModule objects that match the regex lldb.SBTarget.modules => list() of all lldb.SBModule objects in the target SBSymbol now exposes: lldb.SBSymbol.name => python string for demangled symbol name lldb.SBSymbol.mangled => python string for mangled symbol name or None if there is none lldb.SBSymbol.type => lldb.eSymbolType enum value lldb.SBSymbol.addr => SBAddress object that represents the start address for this symbol (if there is one) lldb.SBSymbol.end_addr => SBAddress for the end address of the symbol (if there is one) lldb.SBSymbol.prologue_size => pythin int containing The size of the prologue in bytes lldb.SBSymbol.instructions => SBInstructionList containing all instructions for this symbol SBFunction now also has these new properties in addition to what is already has: lldb.SBFunction.addr => SBAddress object that represents the start address for this function lldb.SBFunction.end_addr => SBAddress for the end address of the function lldb.SBFunction.instructions => SBInstructionList containing all instructions for this function SBFrame now exposes the SBAddress for the frame: lldb.SBFrame.addr => SBAddress which is the section offset address for the current frame PC These are all in addition to what was already added. Documentation and website updates coming soon. llvm-svn: 149489
2012-02-01 08:09:32 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
int new_count = Debugger::TestDebuggerRefCount();
Prevent Python script interpreter initialization from changing the termios settings on the debugger's input handle. llvm-svn: 116725
2010-10-18 18:24:17 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
if (new_count > old_count)
Debugger::Terminate();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
run_string.Clear();
<rdar://problem/12479701> Use the plain pydoc pager to work around Python help() pagination conflicts with our I/O management llvm-svn: 166432
2012-10-22 19:09:28 +00:00
run_string.Printf ("run_one_line (%s, 'lldb.debugger_unique_id = %llu; pydoc.pager = pydoc.plainpager')", m_dictionary_name.c_str(),
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
interpreter.GetDebugger().GetID());
PyRun_SimpleString (run_string.GetData());
if (m_dbg_stdout != NULL)
{
m_new_sysout = PyFile_FromFile (m_dbg_stdout, (char *) "", (char *) "w", _check_and_flush);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
<rdar://problem/11449953> Change Debugger::SetOutputFileHandle() so that it does not automatically initialize the script interpreter in order to transfer its output file handle to it This should delay initialization of Python until strictly necessary and speed-up debugger startup Also, convert formatters for SEL and BOOL ObjC data-types from Python to C++, in order to reap more performance benefits from the above changes llvm-svn: 166967
2012-10-29 21:18:03 +00:00
// get the output file handle from the debugger (if any)
File& out_file = interpreter.GetDebugger().GetOutputFile();
if (out_file.IsValid())
ResetOutputFileHandle(out_file.GetStream());
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
ScriptInterpreterPython::~ScriptInterpreterPython ()
{
Debugger &debugger = GetCommandInterpreter().GetDebugger();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
if (m_embedded_thread_input_reader_sp.get() != NULL)
{
m_embedded_thread_input_reader_sp->SetIsDone (true);
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
m_embedded_thread_pty.CloseSlaveFileDescriptor();
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
const InputReaderSP reader_sp = m_embedded_thread_input_reader_sp;
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
debugger.PopInputReader (reader_sp);
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
m_embedded_thread_input_reader_sp.reset();
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
}
if (m_embedded_python_input_reader_sp.get() != NULL)
{
m_embedded_python_input_reader_sp->SetIsDone (true);
m_embedded_python_pty.CloseSlaveFileDescriptor();
const InputReaderSP reader_sp = m_embedded_python_input_reader_sp;
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
debugger.PopInputReader (reader_sp);
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
m_embedded_python_input_reader_sp.reset();
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
}
if (m_new_sysout)
{
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
Locker locker(this,
ScriptInterpreterPython::Locker::AcquireLock,
ScriptInterpreterPython::Locker::FreeLock);
Py_DECREF ((PyObject*)m_new_sysout);
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
void
ScriptInterpreterPython::ResetOutputFileHandle (FILE *fh)
{
if (fh == NULL)
return;
m_dbg_stdout = fh;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
Fixed a crasher when Xcode calls into ScriptInterpreterPython::ResetOutputFileHandle(). The Locker should only perform acquire/free lock operation, but no enter/leave session at all. Also added sanity checks for items passed to the PyDict_SetItemString() calls. llvm-svn: 152337
2012-03-08 20:53:04 +00:00
Locker locker(this,
ScriptInterpreterPython::Locker::AcquireLock,
ScriptInterpreterPython::Locker::FreeAcquiredLock);
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-06 19:20:51 +00:00
m_new_sysout = PyFile_FromFile (m_dbg_stdout, (char *) "", (char *) "w", _check_and_flush);
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
Abtract terminal stuff into a new lldb_private::Terminal class where the implementation is hidden in the host layer. This avoids a slew of "#if LLDB_CONFIG_TERMIOS_SUPPORTED" statements in the code and keeps things cleaner. llvm-svn: 125057
2011-02-07 23:24:47 +00:00
void
ScriptInterpreterPython::SaveTerminalState (int fd)
{
// Python mucks with the terminal state of STDIN. If we can possibly avoid
// this by setting the file handles up correctly prior to entering the
// interpreter we should. For now we save and restore the terminal state
// on the input file handle.
m_terminal_state.Save (fd, false);
}
void
ScriptInterpreterPython::RestoreTerminalState ()
{
// Python mucks with the terminal state of STDIN. If we can possibly avoid
// this by setting the file handles up correctly prior to entering the
// interpreter we should. For now we save and restore the terminal state
// on the input file handle.
m_terminal_state.Restore();
}
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
void
ScriptInterpreterPython::LeaveSession ()
{
Fixing a potential crasher where Python would assume we have no thread state while clearing out an SBDebugger which was acquiring input from the interactive interpreter llvm-svn: 154027
2012-04-04 17:31:29 +00:00
// checking that we have a valid thread state - since we use our own threading and locking
// in some (rare) cases during cleanup Python may end up believing we have no thread state
// and PyImport_AddModule will crash if that is the case - since that seems to only happen
// when destroying the SBDebugger, we can make do without clearing up stdout and stderr
When the current thread state is NULL, PyThreadState_Get() issues a fatal error. Use a gentler API PyThreadState_GetDict(), instead. rdar://problem/11292882 llvm-svn: 156200
2012-05-04 20:37:11 +00:00
// rdar://problem/11292882
// When the current thread state is NULL, PyThreadState_Get() issues a fatal error.
if (PyThreadState_GetDict())
Patch from Filipe Cabecinhas! Attached is a small python fix to save the current stout and std err when starting a python session, then diverting them (as it was before), and restoring the previous values afterwards. Otherwise, a python script could suddenly find itself without output. llvm-svn: 151693
2012-02-29 01:52:13 +00:00
{
Fixing a potential crasher where Python would assume we have no thread state while clearing out an SBDebugger which was acquiring input from the interactive interpreter llvm-svn: 154027
2012-04-04 17:31:29 +00:00
PyObject *sysmod = PyImport_AddModule ("sys");
PyObject *sysdict = PyModule_GetDict (sysmod);
if (m_new_sysout && sysmod && sysdict)
{
if (m_old_sysout)
PyDict_SetItemString (sysdict, "stdout", (PyObject*)m_old_sysout);
if (m_old_syserr)
PyDict_SetItemString (sysdict, "stderr", (PyObject*)m_old_syserr);
}
Patch from Filipe Cabecinhas! Attached is a small python fix to save the current stout and std err when starting a python session, then diverting them (as it was before), and restoring the previous values afterwards. Otherwise, a python script could suddenly find itself without output. llvm-svn: 151693
2012-02-29 01:52:13 +00:00
}
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
m_session_is_active = false;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
void
ScriptInterpreterPython::EnterSession ()
{
// If we have already entered the session, without having officially 'left' it, then there is no need to
// 'enter' it again.
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
if (m_session_is_active)
return;
Prevent Python script interpreter initialization from changing the termios settings on the debugger's input handle. llvm-svn: 116725
2010-10-18 18:24:17 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
m_session_is_active = true;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
Replace Mutex guarding python interpreter access with Predicate, allowing timeouts & informing the user when the lock is unavailable. Fixed problem where Debugger::Terminate was clearing the debugger list even when the global ref count was greater than zero. llvm-svn: 123674
2011-01-17 21:55:19 +00:00
StreamString run_string;
Stop running so many individual commands when going into the script interpreter. All of the commands now get globbed into a single line. lldb.target, lldb.process, lldb.thread and lldb.frame now get initialized with empty SBTarget, SBProcess, SBThread and SBFrame objects when they don't contain anything. llvm-svn: 149166
2012-01-28 02:11:02 +00:00
run_string.Printf ( "run_one_line (%s, 'lldb.debugger_unique_id = %llu", m_dictionary_name.c_str(), GetCommandInterpreter().GetDebugger().GetID());
run_string.Printf ( "; lldb.debugger = lldb.SBDebugger.FindDebuggerWithID (%llu)", GetCommandInterpreter().GetDebugger().GetID());
run_string.PutCString ("; lldb.target = lldb.debugger.GetSelectedTarget()");
run_string.PutCString ("; lldb.process = lldb.target.GetProcess()");
run_string.PutCString ("; lldb.thread = lldb.process.GetSelectedThread ()");
run_string.PutCString ("; lldb.frame = lldb.thread.GetSelectedFrame ()");
// Make sure STDIN is closed since when we run this as an embedded
// interpreter we don't want someone to call "line = sys.stdin.readline()"
// and lock up. We don't have multiple windows and when the interpreter is
// embedded we don't know we should be feeding input to the embedded
// interpreter or to the python sys.stdin. We also don't want to let python
// play with the real stdin from this process, so we need to close it...
Added support to SBType for getting template arguments from a SBType: uint32_t SBType::GetNumberOfTemplateArguments (); lldb::SBType SBType::GetTemplateArgumentType (uint32_t idx); lldb::TemplateArgumentKind SBType::GetTemplateArgumentKind (uint32_t idx); Some lldb::TemplateArgumentKind values don't have a corresponding SBType that will be returned from SBType::GetTemplateArgumentType(). This will help our data formatters do their job by being able to find out the type of template params and do smart things with those. llvm-svn: 149658
2012-02-03 01:30:30 +00:00
//run_string.PutCString ("; sys.stdin.close()");
Stop running so many individual commands when going into the script interpreter. All of the commands now get globbed into a single line. lldb.target, lldb.process, lldb.thread and lldb.frame now get initialized with empty SBTarget, SBProcess, SBThread and SBFrame objects when they don't contain anything. llvm-svn: 149166
2012-01-28 02:11:02 +00:00
run_string.PutCString ("')");
Pre-load the Python script interpreter with the following convenience variables (from the ExecutionContext) each time it is entered: lldb.debugger, lldb.target, lldb.process, lldb.thread, lldb.frame. If a frame (or thread, process, etc) does not currently exist, the variable contains the Python value 'None'. llvm-svn: 130792
2011-05-03 21:21:50 +00:00
PyRun_SimpleString (run_string.GetData());
run_string.Clear();
Patch from Filipe Cabecinhas! Attached is a small python fix to save the current stout and std err when starting a python session, then diverting them (as it was before), and restoring the previous values afterwards. Otherwise, a python script could suddenly find itself without output. llvm-svn: 151693
2012-02-29 01:52:13 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
PyObject *sysmod = PyImport_AddModule ("sys");
PyObject *sysdict = PyModule_GetDict (sysmod);
Patch from Filipe Cabecinhas! Attached is a small python fix to save the current stout and std err when starting a python session, then diverting them (as it was before), and restoring the previous values afterwards. Otherwise, a python script could suddenly find itself without output. llvm-svn: 151693
2012-02-29 01:52:13 +00:00
Stop running so many individual commands when going into the script interpreter. All of the commands now get globbed into a single line. lldb.target, lldb.process, lldb.thread and lldb.frame now get initialized with empty SBTarget, SBProcess, SBThread and SBFrame objects when they don't contain anything. llvm-svn: 149166
2012-01-28 02:11:02 +00:00
if (m_new_sysout && sysmod && sysdict)
{
Patch from Filipe Cabecinhas! Attached is a small python fix to save the current stout and std err when starting a python session, then diverting them (as it was before), and restoring the previous values afterwards. Otherwise, a python script could suddenly find itself without output. llvm-svn: 151693
2012-02-29 01:52:13 +00:00
m_old_sysout = PyDict_GetItemString(sysdict, "stdout");
m_old_syserr = PyDict_GetItemString(sysdict, "stderr");
Fixed a crasher when Xcode calls into ScriptInterpreterPython::ResetOutputFileHandle(). The Locker should only perform acquire/free lock operation, but no enter/leave session at all. Also added sanity checks for items passed to the PyDict_SetItemString() calls. llvm-svn: 152337
2012-03-08 20:53:04 +00:00
if (m_new_sysout)
{
PyDict_SetItemString (sysdict, "stdout", (PyObject*)m_new_sysout);
PyDict_SetItemString (sysdict, "stderr", (PyObject*)m_new_sysout);
}
Stop running so many individual commands when going into the script interpreter. All of the commands now get globbed into a single line. lldb.target, lldb.process, lldb.thread and lldb.frame now get initialized with empty SBTarget, SBProcess, SBThread and SBFrame objects when they don't contain anything. llvm-svn: 149166
2012-01-28 02:11:02 +00:00
}
Patch from Filipe Cabecinhas! Attached is a small python fix to save the current stout and std err when starting a python session, then diverting them (as it was before), and restoring the previous values afterwards. Otherwise, a python script could suddenly find itself without output. llvm-svn: 151693
2012-02-29 01:52:13 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
if (PyErr_Occurred())
PyErr_Clear ();
Stop running so many individual commands when going into the script interpreter. All of the commands now get globbed into a single line. lldb.target, lldb.process, lldb.thread and lldb.frame now get initialized with empty SBTarget, SBProcess, SBThread and SBFrame objects when they don't contain anything. llvm-svn: 149166
2012-01-28 02:11:02 +00:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
static PyObject*
FindSessionDictionary (const char* dict_name)
{
static std::map<ConstString,PyObject*> g_dict_map;
ConstString dict(dict_name);
std::map<ConstString,PyObject*>::iterator iter = g_dict_map.find(dict);
if (iter != g_dict_map.end())
return iter->second;
PyObject *main_mod = PyImport_AddModule ("__main__");
if (main_mod != NULL)
{
PyObject *main_dict = PyModule_GetDict (main_mod);
if ((main_dict != NULL)
&& PyDict_Check (main_dict))
{
// Go through the main dictionary looking for the correct python script interpreter dictionary
PyObject *key, *value;
Py_ssize_t pos = 0;
while (PyDict_Next (main_dict, &pos, &key, &value))
{
// We have stolen references to the key and value objects in the dictionary; we need to increment
// them now so that Python's garbage collector doesn't collect them out from under us.
Py_INCREF (key);
Py_INCREF (value);
if (strcmp (PyString_AsString (key), dict_name) == 0)
{
g_dict_map[dict] = value;
return value;
}
}
}
}
return NULL;
}
static std::string
GenerateUniqueName (const char* base_name_wanted,
uint32_t& functions_counter,
void* name_token = NULL)
{
StreamString sstr;
if (!base_name_wanted)
return std::string();
if (!name_token)
sstr.Printf ("%s_%d", base_name_wanted, functions_counter++);
else
sstr.Printf ("%s_%p", base_name_wanted, name_token);
return sstr.GetString();
}
We can do better when reporting the status of one-liner script execution. Change the prototype of ScriptInterpreter::ExecuteOneLine() to return bool instead of void and take one additional parameter as CommandReturnObject *. Propagate the status of one-liner execution back appropriately. llvm-svn: 109899
2010-07-30 22:33:14 +00:00
bool
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
ScriptInterpreterPython::ExecuteOneLine (const char *command, CommandReturnObject *result, const ExecuteScriptOptions &options)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
if (!m_valid_session)
return false;
Recent modifications to the Python script interpreter caused some problems when handling one-liner commands that contain escaped characters. In order to deal with the new namespace/dictionary stuff, the command was being embedded within a second string, which messed up the escaping. This fixes the problem by handling one-liners in a different manner, so they no longer need to be embedded within another string, and can still be processed in the proper namespace/dictionary context. llvm-svn: 123467
2011-01-14 21:09:29 +00:00
// We want to call run_one_line, passing in the dictionary and the command string. We cannot do this through
// PyRun_SimpleString here because the command string may contain escaped characters, and putting it inside
// another string to pass to PyRun_SimpleString messes up the escaping. So we use the following more complicated
// method to pass the command string directly down to Python.
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
Locker locker(this,
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
ScriptInterpreterPython::Locker::AcquireLock | (options.GetSetLLDBGlobals() ? ScriptInterpreterPython::Locker::InitSession : 0),
ScriptInterpreterPython::Locker::FreeAcquiredLock | (options.GetSetLLDBGlobals() ? ScriptInterpreterPython::Locker::TearDownSession : 0));
Recent modifications to the Python script interpreter caused some problems when handling one-liner commands that contain escaped characters. In order to deal with the new namespace/dictionary stuff, the command was being embedded within a second string, which messed up the escaping. This fixes the problem by handling one-liners in a different manner, so they no longer need to be embedded within another string, and can still be processed in the proper namespace/dictionary context. llvm-svn: 123467
2011-01-14 21:09:29 +00:00
bool success = false;
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 01:19:29 +00:00
if (command)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
Recent modifications to the Python script interpreter caused some problems when handling one-liner commands that contain escaped characters. In order to deal with the new namespace/dictionary stuff, the command was being embedded within a second string, which messed up the escaping. This fixes the problem by handling one-liners in a different manner, so they no longer need to be embedded within another string, and can still be processed in the proper namespace/dictionary context. llvm-svn: 123467
2011-01-14 21:09:29 +00:00
// Find the correct script interpreter dictionary in the main module.
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
PyObject *script_interpreter_dict = FindSessionDictionary(m_dictionary_name.c_str());
if (script_interpreter_dict != NULL)
Recent modifications to the Python script interpreter caused some problems when handling one-liner commands that contain escaped characters. In order to deal with the new namespace/dictionary stuff, the command was being embedded within a second string, which messed up the escaping. This fixes the problem by handling one-liners in a different manner, so they no longer need to be embedded within another string, and can still be processed in the proper namespace/dictionary context. llvm-svn: 123467
2011-01-14 21:09:29 +00:00
{
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
PyObject *pfunc = (PyObject*)m_run_one_line;
Now that we have an LLDB package, make the "lldb.macosx.crashlog" module work with all of the new module paths. llvm-svn: 155528
2012-04-25 01:49:50 +00:00
PyObject *pmod = PyImport_AddModule ("lldb.embedded_interpreter");
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
if (pmod != NULL)
Recent modifications to the Python script interpreter caused some problems when handling one-liner commands that contain escaped characters. In order to deal with the new namespace/dictionary stuff, the command was being embedded within a second string, which messed up the escaping. This fixes the problem by handling one-liners in a different manner, so they no longer need to be embedded within another string, and can still be processed in the proper namespace/dictionary context. llvm-svn: 123467
2011-01-14 21:09:29 +00:00
{
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
PyObject *pmod_dict = PyModule_GetDict (pmod);
if ((pmod_dict != NULL)
&& PyDict_Check (pmod_dict))
Recent modifications to the Python script interpreter caused some problems when handling one-liner commands that contain escaped characters. In order to deal with the new namespace/dictionary stuff, the command was being embedded within a second string, which messed up the escaping. This fixes the problem by handling one-liners in a different manner, so they no longer need to be embedded within another string, and can still be processed in the proper namespace/dictionary context. llvm-svn: 123467
2011-01-14 21:09:29 +00:00
{
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
if (!pfunc)
Recent modifications to the Python script interpreter caused some problems when handling one-liner commands that contain escaped characters. In order to deal with the new namespace/dictionary stuff, the command was being embedded within a second string, which messed up the escaping. This fixes the problem by handling one-liners in a different manner, so they no longer need to be embedded within another string, and can still be processed in the proper namespace/dictionary context. llvm-svn: 123467
2011-01-14 21:09:29 +00:00
{
PyObject *key, *value;
Py_ssize_t pos = 0;
while (PyDict_Next (pmod_dict, &pos, &key, &value))
{
Py_INCREF (key);
Py_INCREF (value);
if (strcmp (PyString_AsString (key), "run_one_line") == 0)
{
pfunc = value;
break;
}
}
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
m_run_one_line = pfunc;
}
if (pfunc && PyCallable_Check (pfunc))
{
PyObject *pargs = Py_BuildValue("(Os)",script_interpreter_dict,command);
if (pargs != NULL)
Recent modifications to the Python script interpreter caused some problems when handling one-liner commands that contain escaped characters. In order to deal with the new namespace/dictionary stuff, the command was being embedded within a second string, which messed up the escaping. This fixes the problem by handling one-liners in a different manner, so they no longer need to be embedded within another string, and can still be processed in the proper namespace/dictionary context. llvm-svn: 123467
2011-01-14 21:09:29 +00:00
{
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
PyObject *pvalue = NULL;
{ // scope for PythonInputReaderManager
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
PythonInputReaderManager py_input(options.GetEnableIO() ? this : NULL);
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
pvalue = PyObject_CallObject (pfunc, pargs);
}
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
Py_DECREF (pargs);
if (pvalue != NULL)
{
Py_DECREF (pvalue);
success = true;
}
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
else if (options.GetMaskoutErrors() && PyErr_Occurred ())
Recent modifications to the Python script interpreter caused some problems when handling one-liner commands that contain escaped characters. In order to deal with the new namespace/dictionary stuff, the command was being embedded within a second string, which messed up the escaping. This fixes the problem by handling one-liners in a different manner, so they no longer need to be embedded within another string, and can still be processed in the proper namespace/dictionary context. llvm-svn: 123467
2011-01-14 21:09:29 +00:00
{
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
PyErr_Print();
PyErr_Clear();
Recent modifications to the Python script interpreter caused some problems when handling one-liner commands that contain escaped characters. In order to deal with the new namespace/dictionary stuff, the command was being embedded within a second string, which messed up the escaping. This fixes the problem by handling one-liners in a different manner, so they no longer need to be embedded within another string, and can still be processed in the proper namespace/dictionary context. llvm-svn: 123467
2011-01-14 21:09:29 +00:00
}
}
}
}
}
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
Py_INCREF (script_interpreter_dict);
Recent modifications to the Python script interpreter caused some problems when handling one-liner commands that contain escaped characters. In order to deal with the new namespace/dictionary stuff, the command was being embedded within a second string, which messed up the escaping. This fixes the problem by handling one-liners in a different manner, so they no longer need to be embedded within another string, and can still be processed in the proper namespace/dictionary context. llvm-svn: 123467
2011-01-14 21:09:29 +00:00
}
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 01:19:29 +00:00
Recent modifications to the Python script interpreter caused some problems when handling one-liner commands that contain escaped characters. In order to deal with the new namespace/dictionary stuff, the command was being embedded within a second string, which messed up the escaping. This fixes the problem by handling one-liners in a different manner, so they no longer need to be embedded within another string, and can still be processed in the proper namespace/dictionary context. llvm-svn: 123467
2011-01-14 21:09:29 +00:00
if (success)
We can do better when reporting the status of one-liner script execution. Change the prototype of ScriptInterpreter::ExecuteOneLine() to return bool instead of void and take one additional parameter as CommandReturnObject *. Propagate the status of one-liner execution back appropriately. llvm-svn: 109899
2010-07-30 22:33:14 +00:00
return true;
// The one-liner failed. Append the error message.
if (result)
result->AppendErrorWithFormat ("python failed attempting to evaluate '%s'\n", command);
return false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
We can do better when reporting the status of one-liner script execution. Change the prototype of ScriptInterpreter::ExecuteOneLine() to return bool instead of void and take one additional parameter as CommandReturnObject *. Propagate the status of one-liner execution back appropriately. llvm-svn: 109899
2010-07-30 22:33:14 +00:00
if (result)
result->AppendError ("empty command passed to python\n");
return false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
size_t
ScriptInterpreterPython::InputReaderCallback
(
void *baton,
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 01:19:29 +00:00
InputReader &reader,
More SWIG cleanup. Moved the breakpoint callback function back to the ScriptInterpreterPython class and made a simple callback function that ScriptInterpreterPython::BreakpointCallbackFunction() now calls so we don't include any internal API stuff into the cpp file that is generated by SWIG. Fixed a few build warnings in debugserver. llvm-svn: 115926
2010-10-07 17:14:24 +00:00
InputReaderAction notification,
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
const char *bytes,
size_t bytes_len
)
{
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
lldb::thread_t embedded_interpreter_thread;
LogSP log (lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_SCRIPT));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
if (baton == NULL)
return 0;
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
ScriptInterpreterPython *script_interpreter = (ScriptInterpreterPython *) baton;
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
if (script_interpreter->m_script_lang != eScriptLanguagePython)
return 0;
Add 'batch_mode' to CommandInterpreter. Modify InputReaders to not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
2011-06-16 16:27:19 +00:00
StreamSP out_stream = reader.GetDebugger().GetAsyncOutputStream();
bool batch_mode = reader.GetDebugger().GetCommandInterpreter().GetBatchCommandMode();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
switch (notification)
{
case eInputReaderActivate:
{
Add 'batch_mode' to CommandInterpreter. Modify InputReaders to not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
2011-06-16 16:27:19 +00:00
if (!batch_mode)
{
out_stream->Printf ("Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.\n");
out_stream->Flush();
}
Use Host::File in lldb_private::StreamFile and other places to cleanup host layer a bit more. llvm-svn: 125149
2011-02-09 01:08:52 +00:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
// Save terminal settings if we can
Use Host::File in lldb_private::StreamFile and other places to cleanup host layer a bit more. llvm-svn: 125149
2011-02-09 01:08:52 +00:00
int input_fd = reader.GetDebugger().GetInputFile().GetDescriptor();
if (input_fd == File::kInvalidDescriptor)
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-17 22:03:32 +00:00
input_fd = STDIN_FILENO;
Remove help text that is no longer correct. Fix Python script interpreter to not fail when the Debugger does not have input/output file handles. llvm-svn: 113880
2010-09-14 22:49:06 +00:00
Abtract terminal stuff into a new lldb_private::Terminal class where the implementation is hidden in the host layer. This avoids a slew of "#if LLDB_CONFIG_TERMIOS_SUPPORTED" statements in the code and keeps things cleaner. llvm-svn: 125057
2011-02-07 23:24:47 +00:00
script_interpreter->SaveTerminalState(input_fd);
More termios fixes from Kirk Beitz. llvm-svn: 125024
2011-02-07 19:04:58 +00:00
Replace Mutex guarding python interpreter access with Predicate, allowing timeouts & informing the user when the lock is unavailable. Fixed problem where Debugger::Terminate was clearing the debugger list even when the global ref count was greater than zero. llvm-svn: 123674
2011-01-17 21:55:19 +00:00
{
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
ScriptInterpreterPython::Locker locker(script_interpreter,
ScriptInterpreterPython::Locker::AcquireLock | ScriptInterpreterPython::Locker::InitSession,
ScriptInterpreterPython::Locker::FreeAcquiredLock);
Replace Mutex guarding python interpreter access with Predicate, allowing timeouts & informing the user when the lock is unavailable. Fixed problem where Debugger::Terminate was clearing the debugger list even when the global ref count was greater than zero. llvm-svn: 123674
2011-01-17 21:55:19 +00:00
}
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
char error_str[1024];
if (script_interpreter->m_embedded_python_pty.OpenFirstAvailableMaster (O_RDWR|O_NOCTTY, error_str,
sizeof(error_str)))
{
if (log)
log->Printf ("ScriptInterpreterPython::InputReaderCallback, Activate, succeeded in opening master pty (fd = %d).",
script_interpreter->m_embedded_python_pty.GetMasterFileDescriptor());
embedded_interpreter_thread = Host::ThreadCreate ("<lldb.script-interpreter.embedded-python-loop>",
ScriptInterpreterPython::RunEmbeddedPythonInterpreter,
script_interpreter, NULL);
Patch that allows for thread_t to be something more complex than an integer. Modified patch from Kirk Beitz. llvm-svn: 125067
2011-02-08 01:34:25 +00:00
if (IS_VALID_LLDB_HOST_THREAD(embedded_interpreter_thread))
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
{
if (log)
One last printf-style call cleanup. llvm-svn: 140205
2011-09-20 23:23:44 +00:00
log->Printf ("ScriptInterpreterPython::InputReaderCallback, Activate, succeeded in creating thread (thread_t = %p)", embedded_interpreter_thread);
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
Error detach_error;
Host::ThreadDetach (embedded_interpreter_thread, &detach_error);
}
else
{
if (log)
log->Printf ("ScriptInterpreterPython::InputReaderCallback, Activate, failed in creating thread");
reader.SetIsDone (true);
}
}
else
{
if (log)
log->Printf ("ScriptInterpreterPython::InputReaderCallback, Activate, failed to open master pty ");
reader.SetIsDone (true);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
break;
case eInputReaderDeactivate:
<rdar://problem/10649734> Fixed an issue where the python interpreter could deadlock LLDB. llvm-svn: 147640
2012-01-06 00:47:38 +00:00
// When another input reader is pushed, don't leave the session...
//script_interpreter->LeaveSession ();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
break;
case eInputReaderReactivate:
Replace Mutex guarding python interpreter access with Predicate, allowing timeouts & informing the user when the lock is unavailable. Fixed problem where Debugger::Terminate was clearing the debugger list even when the global ref count was greater than zero. llvm-svn: 123674
2011-01-17 21:55:19 +00:00
{
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
ScriptInterpreterPython::Locker locker(script_interpreter,
ScriptInterpreterPython::Locker::AcquireLock | ScriptInterpreterPython::Locker::InitSession,
ScriptInterpreterPython::Locker::FreeAcquiredLock);
Replace Mutex guarding python interpreter access with Predicate, allowing timeouts & informing the user when the lock is unavailable. Fixed problem where Debugger::Terminate was clearing the debugger list even when the global ref count was greater than zero. llvm-svn: 123674
2011-01-17 21:55:19 +00:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
break;
Add the ability to catch and do the right thing with Interrupts (often control-c) and end-of-file (often control-d). llvm-svn: 119837
2010-11-19 20:47:54 +00:00
This patch captures and serializes all output being written by the command line driver, including the lldb prompt being output by editline, the asynchronous process output & error messages, and asynchronous messages written by target stop-hooks. As part of this it introduces a new Stream class, StreamAsynchronousIO. A StreamAsynchronousIO object is created with a broadcaster, who will eventually broadcast the stream's data for a listener to handle, and an event type indicating what type of event the broadcaster will broadcast. When the Write method is called on a StreamAsynchronousIO object, the data is appended to an internal string. When the Flush method is called on a StreamAsynchronousIO object, it broadcasts it's data string and clears the string. Anything in lldb-core that needs to generate asynchronous output for the end-user should use the StreamAsynchronousIO objects. I have also added a new notification type for InputReaders, to let them know that a asynchronous output has been written. This is to allow the input readers to, for example, refresh their prompts and lines, if desired. I added the case statements to all the input readers to catch this notification, but I haven't added any code for handling them yet (except to the IOChannel input reader). llvm-svn: 130721
2011-05-02 20:41:46 +00:00
case eInputReaderAsynchronousOutputWritten:
break;
Add the ability to catch and do the right thing with Interrupts (often control-c) and end-of-file (often control-d). llvm-svn: 119837
2010-11-19 20:47:54 +00:00
case eInputReaderInterrupt:
::write (script_interpreter->m_embedded_python_pty.GetMasterFileDescriptor(), "raise KeyboardInterrupt\n", 24);
break;
case eInputReaderEndOfFile:
::write (script_interpreter->m_embedded_python_pty.GetMasterFileDescriptor(), "quit()\n", 7);
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
case eInputReaderGotToken:
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
if (script_interpreter->m_embedded_python_pty.GetMasterFileDescriptor() != -1)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
if (log)
Update declarations for all functions/methods that accept printf-style stdarg formats to use __attribute__ format so the compiler can flag incorrect uses. Fix all incorrect uses. Most of these are innocuous, a few were resulting in crashes. llvm-svn: 140185
2011-09-20 21:44:10 +00:00
log->Printf ("ScriptInterpreterPython::InputReaderCallback, GotToken, bytes='%s', byte_len = %lu", bytes,
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
bytes_len);
if (bytes && bytes_len)
{
if ((int) bytes[0] == 4)
::write (script_interpreter->m_embedded_python_pty.GetMasterFileDescriptor(), "quit()", 6);
else
::write (script_interpreter->m_embedded_python_pty.GetMasterFileDescriptor(), bytes, bytes_len);
}
::write (script_interpreter->m_embedded_python_pty.GetMasterFileDescriptor(), "\n", 1);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
else
{
if (log)
Update declarations for all functions/methods that accept printf-style stdarg formats to use __attribute__ format so the compiler can flag incorrect uses. Fix all incorrect uses. Most of these are innocuous, a few were resulting in crashes. llvm-svn: 140185
2011-09-20 21:44:10 +00:00
log->Printf ("ScriptInterpreterPython::InputReaderCallback, GotToken, bytes='%s', byte_len = %lu, Master File Descriptor is bad.",
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
bytes,
bytes_len);
reader.SetIsDone (true);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
break;
case eInputReaderDone:
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
{
Locker locker(script_interpreter,
ScriptInterpreterPython::Locker::AcquireLock,
ScriptInterpreterPython::Locker::FreeAcquiredLock);
script_interpreter->LeaveSession ();
}
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
// Restore terminal settings if they were validly saved
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
if (log)
log->Printf ("ScriptInterpreterPython::InputReaderCallback, Done, closing down input reader.");
Remove help text that is no longer correct. Fix Python script interpreter to not fail when the Debugger does not have input/output file handles. llvm-svn: 113880
2010-09-14 22:49:06 +00:00
Abtract terminal stuff into a new lldb_private::Terminal class where the implementation is hidden in the host layer. This avoids a slew of "#if LLDB_CONFIG_TERMIOS_SUPPORTED" statements in the code and keeps things cleaner. llvm-svn: 125057
2011-02-07 23:24:47 +00:00
script_interpreter->RestoreTerminalState ();
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
script_interpreter->m_embedded_python_pty.CloseMasterFileDescriptor();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
break;
}
return bytes_len;
}
void
Fixed the way set/show variables were being accessed to being natively accessed by the objects that own the settings. The previous approach wasn't very usable and made for a lot of unnecessary code just to access variables that were already owned by the objects. While I fixed those things, I saw that CommandObject objects should really have a reference to their command interpreter so they can access the terminal with if they want to output usaage. Fixed up all CommandObjects to take an interpreter and cleaned up the API to not need the interpreter to be passed in. Fixed the disassemble command to output the usage if no options are passed down and arguments are passed (all disassebmle variants take options, there are no "args only"). llvm-svn: 114252
2010-09-18 01:14:36 +00:00
ScriptInterpreterPython::ExecuteInterpreterLoop ()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
Timer scoped_timer (__PRETTY_FUNCTION__, __PRETTY_FUNCTION__);
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Debugger &debugger = GetCommandInterpreter().GetDebugger();
Remove help text that is no longer correct. Fix Python script interpreter to not fail when the Debugger does not have input/output file handles. llvm-svn: 113880
2010-09-14 22:49:06 +00:00
// At the moment, the only time the debugger does not have an input file handle is when this is called
// directly from Python, in which case it is both dangerous and unnecessary (not to mention confusing) to
// try to embed a running interpreter loop inside the already running Python interpreter loop, so we won't
// do it.
Use Host::File in lldb_private::StreamFile and other places to cleanup host layer a bit more. llvm-svn: 125149
2011-02-09 01:08:52 +00:00
if (!debugger.GetInputFile().IsValid())
Remove help text that is no longer correct. Fix Python script interpreter to not fail when the Debugger does not have input/output file handles. llvm-svn: 113880
2010-09-14 22:49:06 +00:00
return;
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 01:19:29 +00:00
InputReaderSP reader_sp (new InputReader(debugger));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
if (reader_sp)
{
Error error (reader_sp->Initialize (ScriptInterpreterPython::InputReaderCallback,
this, // baton
eInputReaderGranularityLine, // token size, to pass to callback function
NULL, // end token
NULL, // prompt
true)); // echo input
if (error.Success())
{
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 01:19:29 +00:00
debugger.PushInputReader (reader_sp);
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
m_embedded_python_input_reader_sp = reader_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
}
}
bool
ScriptInterpreterPython::ExecuteOneLineWithReturn (const char *in_string,
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
ScriptInterpreter::ScriptReturnType return_type,
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
void *ret_value,
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
const ExecuteScriptOptions &options)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
Locker locker(this,
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
ScriptInterpreterPython::Locker::AcquireLock | (options.GetSetLLDBGlobals() ? ScriptInterpreterPython::Locker::InitSession : 0),
ScriptInterpreterPython::Locker::FreeAcquiredLock | (options.GetSetLLDBGlobals() ? ScriptInterpreterPython::Locker::TearDownSession : 0));
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
PyObject *py_return = NULL;
PyObject *mainmod = PyImport_AddModule ("__main__");
PyObject *globals = PyModule_GetDict (mainmod);
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
PyObject *locals = NULL;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
PyObject *py_error = NULL;
To silence the static analyzer. llvm-svn: 137329
2011-08-11 19:17:45 +00:00
bool ret_success = false;
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
bool should_decrement_locals = false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
int success;
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
locals = FindSessionDictionary(m_dictionary_name.c_str());
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
if (locals == NULL)
{
locals = PyObject_GetAttrString (globals, m_dictionary_name.c_str());
should_decrement_locals = true;
}
if (locals == NULL)
{
locals = globals;
should_decrement_locals = false;
}
py_error = PyErr_Occurred();
if (py_error != NULL)
PyErr_Clear();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
if (in_string != NULL)
{
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
{ // scope for PythonInputReaderManager
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
PythonInputReaderManager py_input(options.GetEnableIO() ? this : NULL);
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
py_return = PyRun_String (in_string, Py_eval_input, globals, locals);
if (py_return == NULL)
{
py_error = PyErr_Occurred ();
if (py_error != NULL)
PyErr_Clear ();
py_return = PyRun_String (in_string, Py_single_input, globals, locals);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
if (locals != NULL
&& should_decrement_locals)
Py_DECREF (locals);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
if (py_return != NULL)
{
switch (return_type)
{
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
case eScriptReturnTypeCharPtr: // "char *"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
const char format[3] = "s#";
When defining a scripted command, it is possible to provide a docstring and that will be used as the help text for the command If no docstring is provided, a default help text is created LLDB will refuse to create scripted commands if the scripting language is anything but Python Some additional comments in AppleObjCRuntimeV2.cpp to describe the memory layout expected by the dynamic type lookup code llvm-svn: 137801
2011-08-17 01:30:04 +00:00
success = PyArg_Parse (py_return, format, (char **) ret_value);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
break;
}
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
case eScriptReturnTypeCharStrOrNone: // char* or NULL if py_return == Py_None
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
{
const char format[3] = "z";
When defining a scripted command, it is possible to provide a docstring and that will be used as the help text for the command If no docstring is provided, a default help text is created LLDB will refuse to create scripted commands if the scripting language is anything but Python Some additional comments in AppleObjCRuntimeV2.cpp to describe the memory layout expected by the dynamic type lookup code llvm-svn: 137801
2011-08-17 01:30:04 +00:00
success = PyArg_Parse (py_return, format, (char **) ret_value);
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
break;
}
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
case eScriptReturnTypeBool:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
const char format[2] = "b";
success = PyArg_Parse (py_return, format, (bool *) ret_value);
break;
}
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
case eScriptReturnTypeShortInt:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
const char format[2] = "h";
success = PyArg_Parse (py_return, format, (short *) ret_value);
break;
}
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
case eScriptReturnTypeShortIntUnsigned:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
const char format[2] = "H";
success = PyArg_Parse (py_return, format, (unsigned short *) ret_value);
break;
}
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
case eScriptReturnTypeInt:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
const char format[2] = "i";
success = PyArg_Parse (py_return, format, (int *) ret_value);
break;
}
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
case eScriptReturnTypeIntUnsigned:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
const char format[2] = "I";
success = PyArg_Parse (py_return, format, (unsigned int *) ret_value);
break;
}
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
case eScriptReturnTypeLongInt:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
const char format[2] = "l";
success = PyArg_Parse (py_return, format, (long *) ret_value);
break;
}
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
case eScriptReturnTypeLongIntUnsigned:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
const char format[2] = "k";
success = PyArg_Parse (py_return, format, (unsigned long *) ret_value);
break;
}
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
case eScriptReturnTypeLongLong:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
const char format[2] = "L";
success = PyArg_Parse (py_return, format, (long long *) ret_value);
break;
}
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
case eScriptReturnTypeLongLongUnsigned:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
const char format[2] = "K";
success = PyArg_Parse (py_return, format, (unsigned long long *) ret_value);
break;
}
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
case eScriptReturnTypeFloat:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
const char format[2] = "f";
success = PyArg_Parse (py_return, format, (float *) ret_value);
break;
}
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
case eScriptReturnTypeDouble:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
const char format[2] = "d";
success = PyArg_Parse (py_return, format, (double *) ret_value);
break;
}
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
case eScriptReturnTypeChar:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
const char format[2] = "c";
success = PyArg_Parse (py_return, format, (char *) ret_value);
break;
}
default:
{}
}
Py_DECREF (py_return);
if (success)
ret_success = true;
else
ret_success = false;
}
}
py_error = PyErr_Occurred();
if (py_error != NULL)
{
ret_success = false;
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
if (options.GetMaskoutErrors())
{
if (PyErr_GivenExceptionMatches (py_error, PyExc_SyntaxError))
PyErr_Print ();
PyErr_Clear();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
Replace Mutex guarding python interpreter access with Predicate, allowing timeouts & informing the user when the lock is unavailable. Fixed problem where Debugger::Terminate was clearing the debugger list even when the global ref count was greater than zero. llvm-svn: 123674
2011-01-17 21:55:19 +00:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
return ret_success;
}
bool
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
ScriptInterpreterPython::ExecuteMultipleLines (const char *in_string, const ExecuteScriptOptions &options)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
Locker locker(this,
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
ScriptInterpreterPython::Locker::AcquireLock | (options.GetSetLLDBGlobals() ? ScriptInterpreterPython::Locker::InitSession : 0),
ScriptInterpreterPython::Locker::FreeAcquiredLock | (options.GetSetLLDBGlobals() ? ScriptInterpreterPython::Locker::TearDownSession : 0));
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
bool success = false;
PyObject *py_return = NULL;
PyObject *mainmod = PyImport_AddModule ("__main__");
PyObject *globals = PyModule_GetDict (mainmod);
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
PyObject *locals = NULL;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
PyObject *py_error = NULL;
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
bool should_decrement_locals = false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
locals = FindSessionDictionary(m_dictionary_name.c_str());
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
if (locals == NULL)
{
locals = PyObject_GetAttrString (globals, m_dictionary_name.c_str());
should_decrement_locals = true;
}
if (locals == NULL)
{
locals = globals;
should_decrement_locals = false;
}
py_error = PyErr_Occurred();
if (py_error != NULL)
PyErr_Clear();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
if (in_string != NULL)
{
struct _node *compiled_node = PyParser_SimpleParseString (in_string, Py_file_input);
if (compiled_node)
{
PyCodeObject *compiled_code = PyNode_Compile (compiled_node, "temp.py");
if (compiled_code)
{
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
{ // scope for PythonInputReaderManager
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
PythonInputReaderManager py_input(options.GetEnableIO() ? this : NULL);
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
py_return = PyEval_EvalCode (compiled_code, globals, locals);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
if (py_return != NULL)
{
success = true;
Py_DECREF (py_return);
}
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
if (locals && should_decrement_locals)
Py_DECREF (locals);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
}
}
py_error = PyErr_Occurred ();
if (py_error != NULL)
{
success = false;
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
if (options.GetMaskoutErrors())
{
if (PyErr_GivenExceptionMatches (py_error, PyExc_SyntaxError))
PyErr_Print ();
PyErr_Clear();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
return success;
}
static const char *g_reader_instructions = "Enter your Python command(s). Type 'DONE' to end.";
size_t
ScriptInterpreterPython::GenerateBreakpointOptionsCommandCallback
(
void *baton,
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 01:19:29 +00:00
InputReader &reader,
More SWIG cleanup. Moved the breakpoint callback function back to the ScriptInterpreterPython class and made a simple callback function that ScriptInterpreterPython::BreakpointCallbackFunction() now calls so we don't include any internal API stuff into the cpp file that is generated by SWIG. Fixed a few build warnings in debugserver. llvm-svn: 115926
2010-10-07 17:14:24 +00:00
InputReaderAction notification,
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
const char *bytes,
size_t bytes_len
)
{
Add 'batch_mode' to CommandInterpreter. Modify InputReaders to not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
2011-06-16 16:27:19 +00:00
static StringList commands_in_progress;
StreamSP out_stream = reader.GetDebugger().GetAsyncOutputStream();
bool batch_mode = reader.GetDebugger().GetCommandInterpreter().GetBatchCommandMode();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
switch (notification)
{
case eInputReaderActivate:
{
commands_in_progress.Clear();
Add 'batch_mode' to CommandInterpreter. Modify InputReaders to not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
2011-06-16 16:27:19 +00:00
if (!batch_mode)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
Add 'batch_mode' to CommandInterpreter. Modify InputReaders to not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
2011-06-16 16:27:19 +00:00
out_stream->Printf ("%s\n", g_reader_instructions);
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 01:19:29 +00:00
if (reader.GetPrompt())
Add 'batch_mode' to CommandInterpreter. Modify InputReaders to not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
2011-06-16 16:27:19 +00:00
out_stream->Printf ("%s", reader.GetPrompt());
out_stream->Flush ();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
}
break;
case eInputReaderDeactivate:
break;
case eInputReaderReactivate:
Add 'batch_mode' to CommandInterpreter. Modify InputReaders to not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
2011-06-16 16:27:19 +00:00
if (reader.GetPrompt() && !batch_mode)
Flush the prompts immediately in the breakpoint command input readers, to make sure they come out at the correct times. llvm-svn: 117470
2010-10-27 18:34:42 +00:00
{
Add 'batch_mode' to CommandInterpreter. Modify InputReaders to not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
2011-06-16 16:27:19 +00:00
out_stream->Printf ("%s", reader.GetPrompt());
out_stream->Flush ();
Flush the prompts immediately in the breakpoint command input readers, to make sure they come out at the correct times. llvm-svn: 117470
2010-10-27 18:34:42 +00:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
break;
This patch captures and serializes all output being written by the command line driver, including the lldb prompt being output by editline, the asynchronous process output & error messages, and asynchronous messages written by target stop-hooks. As part of this it introduces a new Stream class, StreamAsynchronousIO. A StreamAsynchronousIO object is created with a broadcaster, who will eventually broadcast the stream's data for a listener to handle, and an event type indicating what type of event the broadcaster will broadcast. When the Write method is called on a StreamAsynchronousIO object, the data is appended to an internal string. When the Flush method is called on a StreamAsynchronousIO object, it broadcasts it's data string and clears the string. Anything in lldb-core that needs to generate asynchronous output for the end-user should use the StreamAsynchronousIO objects. I have also added a new notification type for InputReaders, to let them know that a asynchronous output has been written. This is to allow the input readers to, for example, refresh their prompts and lines, if desired. I added the case statements to all the input readers to catch this notification, but I haven't added any code for handling them yet (except to the IOChannel input reader). llvm-svn: 130721
2011-05-02 20:41:46 +00:00
case eInputReaderAsynchronousOutputWritten:
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
case eInputReaderGotToken:
{
std::string temp_string (bytes, bytes_len);
commands_in_progress.AppendString (temp_string.c_str());
Add 'batch_mode' to CommandInterpreter. Modify InputReaders to not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
2011-06-16 16:27:19 +00:00
if (!reader.IsDone() && reader.GetPrompt() && !batch_mode)
Flush the prompts immediately in the breakpoint command input readers, to make sure they come out at the correct times. llvm-svn: 117470
2010-10-27 18:34:42 +00:00
{
Add 'batch_mode' to CommandInterpreter. Modify InputReaders to not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
2011-06-16 16:27:19 +00:00
out_stream->Printf ("%s", reader.GetPrompt());
out_stream->Flush ();
Flush the prompts immediately in the breakpoint command input readers, to make sure they come out at the correct times. llvm-svn: 117470
2010-10-27 18:34:42 +00:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
break;
Add the ability to catch and do the right thing with Interrupts (often control-c) and end-of-file (often control-d). llvm-svn: 119837
2010-11-19 20:47:54 +00:00
case eInputReaderEndOfFile:
case eInputReaderInterrupt:
// Control-c (SIGINT) & control-d both mean finish & exit.
reader.SetIsDone(true);
// Control-c (SIGINT) ALSO means cancel; do NOT create a breakpoint command.
if (notification == eInputReaderInterrupt)
commands_in_progress.Clear();
// Fall through here...
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
case eInputReaderDone:
{
BreakpointOptions *bp_options = (BreakpointOptions *)baton;
std::auto_ptr<BreakpointOptions::CommandData> data_ap(new BreakpointOptions::CommandData());
data_ap->user_source.AppendList (commands_in_progress);
if (data_ap.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 01:19:29 +00:00
ScriptInterpreter *interpreter = reader.GetDebugger().GetCommandInterpreter().GetScriptInterpreter();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
if (interpreter)
{
if (interpreter->GenerateBreakpointCommandCallbackData (data_ap->user_source,
data_ap->script_source))
{
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
BatonSP baton_sp (new BreakpointOptions::CommandBaton (data_ap.release()));
bp_options->SetCallback (ScriptInterpreterPython::BreakpointCallbackFunction, baton_sp);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
Add 'batch_mode' to CommandInterpreter. Modify InputReaders to not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
2011-06-16 16:27:19 +00:00
else if (!batch_mode)
{
out_stream->Printf ("Warning: No command attached to breakpoint.\n");
out_stream->Flush();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
else
{
Add 'batch_mode' to CommandInterpreter. Modify InputReaders to not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
2011-06-16 16:27:19 +00:00
if (!batch_mode)
{
out_stream->Printf ("Warning: Unable to find script intepreter; no command attached to breakpoint.\n");
out_stream->Flush();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
}
}
break;
}
return bytes_len;
}
rdar://problem/11457143 [ER] need "watchpoint command ..." Add 'watchpoint command add/delete/list' to lldb, plus two .py test files. llvm-svn: 161638
2012-08-09 23:09:42 +00:00
size_t
ScriptInterpreterPython::GenerateWatchpointOptionsCommandCallback
(
void *baton,
InputReader &reader,
InputReaderAction notification,
const char *bytes,
size_t bytes_len
)
{
static StringList commands_in_progress;
StreamSP out_stream = reader.GetDebugger().GetAsyncOutputStream();
bool batch_mode = reader.GetDebugger().GetCommandInterpreter().GetBatchCommandMode();
switch (notification)
{
case eInputReaderActivate:
{
commands_in_progress.Clear();
if (!batch_mode)
{
out_stream->Printf ("%s\n", g_reader_instructions);
if (reader.GetPrompt())
out_stream->Printf ("%s", reader.GetPrompt());
out_stream->Flush ();
}
}
break;
case eInputReaderDeactivate:
break;
case eInputReaderReactivate:
if (reader.GetPrompt() && !batch_mode)
{
out_stream->Printf ("%s", reader.GetPrompt());
out_stream->Flush ();
}
break;
case eInputReaderAsynchronousOutputWritten:
break;
case eInputReaderGotToken:
{
std::string temp_string (bytes, bytes_len);
commands_in_progress.AppendString (temp_string.c_str());
if (!reader.IsDone() && reader.GetPrompt() && !batch_mode)
{
out_stream->Printf ("%s", reader.GetPrompt());
out_stream->Flush ();
}
}
break;
case eInputReaderEndOfFile:
case eInputReaderInterrupt:
// Control-c (SIGINT) & control-d both mean finish & exit.
reader.SetIsDone(true);
// Control-c (SIGINT) ALSO means cancel; do NOT create a breakpoint command.
if (notification == eInputReaderInterrupt)
commands_in_progress.Clear();
// Fall through here...
case eInputReaderDone:
{
WatchpointOptions *wp_options = (WatchpointOptions *)baton;
std::auto_ptr<WatchpointOptions::CommandData> data_ap(new WatchpointOptions::CommandData());
data_ap->user_source.AppendList (commands_in_progress);
if (data_ap.get())
{
ScriptInterpreter *interpreter = reader.GetDebugger().GetCommandInterpreter().GetScriptInterpreter();
if (interpreter)
{
if (interpreter->GenerateWatchpointCommandCallbackData (data_ap->user_source,
data_ap->script_source))
{
BatonSP baton_sp (new WatchpointOptions::CommandBaton (data_ap.release()));
wp_options->SetCallback (ScriptInterpreterPython::WatchpointCallbackFunction, baton_sp);
}
else if (!batch_mode)
{
out_stream->Printf ("Warning: No command attached to breakpoint.\n");
out_stream->Flush();
}
}
else
{
if (!batch_mode)
{
out_stream->Printf ("Warning: Unable to find script intepreter; no command attached to breakpoint.\n");
out_stream->Flush();
}
}
}
}
break;
}
return bytes_len;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
void
Fixed the way set/show variables were being accessed to being natively accessed by the objects that own the settings. The previous approach wasn't very usable and made for a lot of unnecessary code just to access variables that were already owned by the objects. While I fixed those things, I saw that CommandObject objects should really have a reference to their command interpreter so they can access the terminal with if they want to output usaage. Fixed up all CommandObjects to take an interpreter and cleaned up the API to not need the interpreter to be passed in. Fixed the disassemble command to output the usage if no options are passed down and arguments are passed (all disassebmle variants take options, there are no "args only"). llvm-svn: 114252
2010-09-18 01:14:36 +00:00
ScriptInterpreterPython::CollectDataForBreakpointCommandCallback (BreakpointOptions *bp_options,
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
CommandReturnObject &result)
{
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Debugger &debugger = GetCommandInterpreter().GetDebugger();
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 01:19:29 +00:00
InputReaderSP reader_sp (new InputReader (debugger));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
if (reader_sp)
{
Error err = reader_sp->Initialize (
ScriptInterpreterPython::GenerateBreakpointOptionsCommandCallback,
bp_options, // baton
eInputReaderGranularityLine, // token size, for feeding data to callback function
"DONE", // end token
"> ", // prompt
true); // echo input
if (err.Success())
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 01:19:29 +00:00
debugger.PushInputReader (reader_sp);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
else
{
result.AppendError (err.AsCString());
result.SetStatus (eReturnStatusFailed);
}
}
else
{
result.AppendError("out of memory");
result.SetStatus (eReturnStatusFailed);
}
}
rdar://problem/11457143 [ER] need "watchpoint command ..." Add 'watchpoint command add/delete/list' to lldb, plus two .py test files. llvm-svn: 161638
2012-08-09 23:09:42 +00:00
void
ScriptInterpreterPython::CollectDataForWatchpointCommandCallback (WatchpointOptions *wp_options,
CommandReturnObject &result)
{
Debugger &debugger = GetCommandInterpreter().GetDebugger();
InputReaderSP reader_sp (new InputReader (debugger));
if (reader_sp)
{
Error err = reader_sp->Initialize (
ScriptInterpreterPython::GenerateWatchpointOptionsCommandCallback,
wp_options, // baton
eInputReaderGranularityLine, // token size, for feeding data to callback function
"DONE", // end token
"> ", // prompt
true); // echo input
if (err.Success())
debugger.PushInputReader (reader_sp);
else
{
result.AppendError (err.AsCString());
result.SetStatus (eReturnStatusFailed);
}
}
else
{
result.AppendError("out of memory");
result.SetStatus (eReturnStatusFailed);
}
}
Fixed some comments. llvm-svn: 113673
2010-09-11 00:23:59 +00:00
// Set a Python one-liner as the callback for the breakpoint.
Added the capability to specify a one-liner Python script as the callback command for a breakpoint, for example: (lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()" The ScriptInterpreter interface has an extra method: /// Set a one-liner as the callback for the breakpoint command. virtual void SetBreakpointCommandCallback (CommandInterpreter &interpreter, BreakpointOptions *bp_options, const char *oneliner); to accomplish the above. Also added a test case to demonstrate lldb's use of breakpoint callback command to stop at function c() only when its immediate caller is function a(). The following session shows the user entering the following commands: 1) command source .lldb (set up executable, breakpoint, and breakpoint command) 2) run (the callback mechanism will skip two breakpoints where c()'s immeidate caller is not a()) 3) bt (to see that indeed c()'s immediate caller is a()) 4) c (to continue and finish the program) test/conditional_break $ ../../build/Debug/lldb (lldb) command source .lldb Executing commands in '.lldb'. (lldb) file a.out Current executable set to 'a.out' (x86_64). (lldb) breakpoint set -n c Breakpoint created: 1: name = 'c', locations = 1 (lldb) script import sys, os (lldb) script sys.path.append(os.path.join(os.getcwd(), os.pardir)) (lldb) script import conditional_break (lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()" (lldb) run run Launching '/Volumes/data/lldb/svn/trunk/test/conditional_break/a.out' (x86_64) (lldb) Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`b at main.c:34 frame #2: a.out`a at main.c:25 frame #3: a.out`main at main.c:44 frame #4: a.out`start c called from b Continuing... Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`b at main.c:34 frame #2: a.out`main at main.c:47 frame #3: a.out`start c called from b Continuing... Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`a at main.c:27 frame #2: a.out`main at main.c:50 frame #3: a.out`start c called from a Stopped at c() with immediate caller as a(). a(1) returns 4 b(2) returns 5 Process 20420 Stopped * thread #1: tid = 0x2e03, 0x0000000100000de8 a.out`c + 7 at main.c:39, stop reason = breakpoint 1.1, queue = com.apple.main-thread 36 37 int c(int val) 38 { 39 -> return val + 3; 40 } 41 42 int main (int argc, char const *argv[]) (lldb) bt bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: 0x0000000100000de8 a.out`c + 7 at main.c:39 frame #1: 0x0000000100000dbc a.out`a + 44 at main.c:27 frame #2: 0x0000000100000e4b a.out`main + 91 at main.c:50 frame #3: 0x0000000100000d88 a.out`start + 52 (lldb) c c Resuming process 20420 Process 20420 Exited a(3) returns 6 (lldb) llvm-svn: 113596
2010-09-10 18:21:10 +00:00
void
Fixed the way set/show variables were being accessed to being natively accessed by the objects that own the settings. The previous approach wasn't very usable and made for a lot of unnecessary code just to access variables that were already owned by the objects. While I fixed those things, I saw that CommandObject objects should really have a reference to their command interpreter so they can access the terminal with if they want to output usaage. Fixed up all CommandObjects to take an interpreter and cleaned up the API to not need the interpreter to be passed in. Fixed the disassemble command to output the usage if no options are passed down and arguments are passed (all disassebmle variants take options, there are no "args only"). llvm-svn: 114252
2010-09-18 01:14:36 +00:00
ScriptInterpreterPython::SetBreakpointCommandCallback (BreakpointOptions *bp_options,
Added the capability to specify a one-liner Python script as the callback command for a breakpoint, for example: (lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()" The ScriptInterpreter interface has an extra method: /// Set a one-liner as the callback for the breakpoint command. virtual void SetBreakpointCommandCallback (CommandInterpreter &interpreter, BreakpointOptions *bp_options, const char *oneliner); to accomplish the above. Also added a test case to demonstrate lldb's use of breakpoint callback command to stop at function c() only when its immediate caller is function a(). The following session shows the user entering the following commands: 1) command source .lldb (set up executable, breakpoint, and breakpoint command) 2) run (the callback mechanism will skip two breakpoints where c()'s immeidate caller is not a()) 3) bt (to see that indeed c()'s immediate caller is a()) 4) c (to continue and finish the program) test/conditional_break $ ../../build/Debug/lldb (lldb) command source .lldb Executing commands in '.lldb'. (lldb) file a.out Current executable set to 'a.out' (x86_64). (lldb) breakpoint set -n c Breakpoint created: 1: name = 'c', locations = 1 (lldb) script import sys, os (lldb) script sys.path.append(os.path.join(os.getcwd(), os.pardir)) (lldb) script import conditional_break (lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()" (lldb) run run Launching '/Volumes/data/lldb/svn/trunk/test/conditional_break/a.out' (x86_64) (lldb) Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`b at main.c:34 frame #2: a.out`a at main.c:25 frame #3: a.out`main at main.c:44 frame #4: a.out`start c called from b Continuing... Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`b at main.c:34 frame #2: a.out`main at main.c:47 frame #3: a.out`start c called from b Continuing... Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`a at main.c:27 frame #2: a.out`main at main.c:50 frame #3: a.out`start c called from a Stopped at c() with immediate caller as a(). a(1) returns 4 b(2) returns 5 Process 20420 Stopped * thread #1: tid = 0x2e03, 0x0000000100000de8 a.out`c + 7 at main.c:39, stop reason = breakpoint 1.1, queue = com.apple.main-thread 36 37 int c(int val) 38 { 39 -> return val + 3; 40 } 41 42 int main (int argc, char const *argv[]) (lldb) bt bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: 0x0000000100000de8 a.out`c + 7 at main.c:39 frame #1: 0x0000000100000dbc a.out`a + 44 at main.c:27 frame #2: 0x0000000100000e4b a.out`main + 91 at main.c:50 frame #3: 0x0000000100000d88 a.out`start + 52 (lldb) c c Resuming process 20420 Process 20420 Exited a(3) returns 6 (lldb) llvm-svn: 113596
2010-09-10 18:21:10 +00:00
const char *oneliner)
{
std::auto_ptr<BreakpointOptions::CommandData> data_ap(new BreakpointOptions::CommandData());
// It's necessary to set both user_source and script_source to the oneliner.
// The former is used to generate callback description (as in breakpoint command list)
// while the latter is used for Python to interpret during the actual callback.
Fix one-liner Python breakpoint commands to be wrapped up in an automatically generated Python function, and passed the stoppoint context frame and bp_loc as parameters. llvm-svn: 114894
2010-09-27 21:35:15 +00:00
data_ap->user_source.AppendString (oneliner);
rdar://problem/11457143 [ER] need "watchpoint command ..." Add 'watchpoint command add/delete/list' to lldb, plus two .py test files. llvm-svn: 161638
2012-08-09 23:09:42 +00:00
data_ap->script_source.assign (oneliner);
Added the capability to specify a one-liner Python script as the callback command for a breakpoint, for example: (lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()" The ScriptInterpreter interface has an extra method: /// Set a one-liner as the callback for the breakpoint command. virtual void SetBreakpointCommandCallback (CommandInterpreter &interpreter, BreakpointOptions *bp_options, const char *oneliner); to accomplish the above. Also added a test case to demonstrate lldb's use of breakpoint callback command to stop at function c() only when its immediate caller is function a(). The following session shows the user entering the following commands: 1) command source .lldb (set up executable, breakpoint, and breakpoint command) 2) run (the callback mechanism will skip two breakpoints where c()'s immeidate caller is not a()) 3) bt (to see that indeed c()'s immediate caller is a()) 4) c (to continue and finish the program) test/conditional_break $ ../../build/Debug/lldb (lldb) command source .lldb Executing commands in '.lldb'. (lldb) file a.out Current executable set to 'a.out' (x86_64). (lldb) breakpoint set -n c Breakpoint created: 1: name = 'c', locations = 1 (lldb) script import sys, os (lldb) script sys.path.append(os.path.join(os.getcwd(), os.pardir)) (lldb) script import conditional_break (lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()" (lldb) run run Launching '/Volumes/data/lldb/svn/trunk/test/conditional_break/a.out' (x86_64) (lldb) Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`b at main.c:34 frame #2: a.out`a at main.c:25 frame #3: a.out`main at main.c:44 frame #4: a.out`start c called from b Continuing... Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`b at main.c:34 frame #2: a.out`main at main.c:47 frame #3: a.out`start c called from b Continuing... Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`a at main.c:27 frame #2: a.out`main at main.c:50 frame #3: a.out`start c called from a Stopped at c() with immediate caller as a(). a(1) returns 4 b(2) returns 5 Process 20420 Stopped * thread #1: tid = 0x2e03, 0x0000000100000de8 a.out`c + 7 at main.c:39, stop reason = breakpoint 1.1, queue = com.apple.main-thread 36 37 int c(int val) 38 { 39 -> return val + 3; 40 } 41 42 int main (int argc, char const *argv[]) (lldb) bt bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: 0x0000000100000de8 a.out`c + 7 at main.c:39 frame #1: 0x0000000100000dbc a.out`a + 44 at main.c:27 frame #2: 0x0000000100000e4b a.out`main + 91 at main.c:50 frame #3: 0x0000000100000d88 a.out`start + 52 (lldb) c c Resuming process 20420 Process 20420 Exited a(3) returns 6 (lldb) llvm-svn: 113596
2010-09-10 18:21:10 +00:00
Fix one-liner Python breakpoint commands to be wrapped up in an automatically generated Python function, and passed the stoppoint context frame and bp_loc as parameters. llvm-svn: 114894
2010-09-27 21:35:15 +00:00
if (GenerateBreakpointCommandCallbackData (data_ap->user_source, data_ap->script_source))
{
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
BatonSP baton_sp (new BreakpointOptions::CommandBaton (data_ap.release()));
bp_options->SetCallback (ScriptInterpreterPython::BreakpointCallbackFunction, baton_sp);
Fix one-liner Python breakpoint commands to be wrapped up in an automatically generated Python function, and passed the stoppoint context frame and bp_loc as parameters. llvm-svn: 114894
2010-09-27 21:35:15 +00:00
}
Added the capability to specify a one-liner Python script as the callback command for a breakpoint, for example: (lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()" The ScriptInterpreter interface has an extra method: /// Set a one-liner as the callback for the breakpoint command. virtual void SetBreakpointCommandCallback (CommandInterpreter &interpreter, BreakpointOptions *bp_options, const char *oneliner); to accomplish the above. Also added a test case to demonstrate lldb's use of breakpoint callback command to stop at function c() only when its immediate caller is function a(). The following session shows the user entering the following commands: 1) command source .lldb (set up executable, breakpoint, and breakpoint command) 2) run (the callback mechanism will skip two breakpoints where c()'s immeidate caller is not a()) 3) bt (to see that indeed c()'s immediate caller is a()) 4) c (to continue and finish the program) test/conditional_break $ ../../build/Debug/lldb (lldb) command source .lldb Executing commands in '.lldb'. (lldb) file a.out Current executable set to 'a.out' (x86_64). (lldb) breakpoint set -n c Breakpoint created: 1: name = 'c', locations = 1 (lldb) script import sys, os (lldb) script sys.path.append(os.path.join(os.getcwd(), os.pardir)) (lldb) script import conditional_break (lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()" (lldb) run run Launching '/Volumes/data/lldb/svn/trunk/test/conditional_break/a.out' (x86_64) (lldb) Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`b at main.c:34 frame #2: a.out`a at main.c:25 frame #3: a.out`main at main.c:44 frame #4: a.out`start c called from b Continuing... Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`b at main.c:34 frame #2: a.out`main at main.c:47 frame #3: a.out`start c called from b Continuing... Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`a at main.c:27 frame #2: a.out`main at main.c:50 frame #3: a.out`start c called from a Stopped at c() with immediate caller as a(). a(1) returns 4 b(2) returns 5 Process 20420 Stopped * thread #1: tid = 0x2e03, 0x0000000100000de8 a.out`c + 7 at main.c:39, stop reason = breakpoint 1.1, queue = com.apple.main-thread 36 37 int c(int val) 38 { 39 -> return val + 3; 40 } 41 42 int main (int argc, char const *argv[]) (lldb) bt bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: 0x0000000100000de8 a.out`c + 7 at main.c:39 frame #1: 0x0000000100000dbc a.out`a + 44 at main.c:27 frame #2: 0x0000000100000e4b a.out`main + 91 at main.c:50 frame #3: 0x0000000100000d88 a.out`start + 52 (lldb) c c Resuming process 20420 Process 20420 Exited a(3) returns 6 (lldb) llvm-svn: 113596
2010-09-10 18:21:10 +00:00
return;
}
rdar://problem/11457143 [ER] need "watchpoint command ..." Add 'watchpoint command add/delete/list' to lldb, plus two .py test files. llvm-svn: 161638
2012-08-09 23:09:42 +00:00
// Set a Python one-liner as the callback for the watchpoint.
void
ScriptInterpreterPython::SetWatchpointCommandCallback (WatchpointOptions *wp_options,
const char *oneliner)
{
std::auto_ptr<WatchpointOptions::CommandData> data_ap(new WatchpointOptions::CommandData());
// It's necessary to set both user_source and script_source to the oneliner.
// The former is used to generate callback description (as in watchpoint command list)
// while the latter is used for Python to interpret during the actual callback.
data_ap->user_source.AppendString (oneliner);
data_ap->script_source.assign (oneliner);
if (GenerateWatchpointCommandCallbackData (data_ap->user_source, data_ap->script_source))
{
BatonSP baton_sp (new WatchpointOptions::CommandBaton (data_ap.release()));
wp_options->SetCallback (ScriptInterpreterPython::WatchpointCallbackFunction, baton_sp);
}
return;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
bool
ScriptInterpreterPython::ExportFunctionDefinitionToInterpreter (StringList &function_def)
{
// Convert StringList to one long, newline delimited, const char *.
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
std::string function_def_string(function_def.CopyList());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
return ExecuteMultipleLines (function_def_string.c_str(), ScriptInterpreter::ExecuteScriptOptions().SetEnableIO(false));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
bool
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
ScriptInterpreterPython::GenerateFunction(const char *signature, const StringList &input)
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
{
int num_lines = input.GetSize ();
if (num_lines == 0)
return false;
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
if (!signature || *signature == 0)
return false;
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
StreamString sstr;
StringList auto_generated_function;
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
auto_generated_function.AppendString (signature);
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
auto_generated_function.AppendString (" global_dict = globals()"); // Grab the global dictionary
<rdar://problem/11975483> Removing user-visible references to 'dict' as a parameter name for Python summary-generating functions since it is a Python keyword. llvm-svn: 161467
2012-08-08 02:06:30 +00:00
auto_generated_function.AppendString (" new_keys = internal_dict.keys()"); // Make a list of keys in the session dict
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
auto_generated_function.AppendString (" old_keys = global_dict.keys()"); // Save list of keys in global dict
<rdar://problem/11975483> Removing user-visible references to 'dict' as a parameter name for Python summary-generating functions since it is a Python keyword. llvm-svn: 161467
2012-08-08 02:06:30 +00:00
auto_generated_function.AppendString (" global_dict.update (internal_dict)"); // Add the session dictionary to the
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
// global dictionary.
// Wrap everything up inside the function, increasing the indentation.
for (int i = 0; i < num_lines; ++i)
{
sstr.Clear ();
sstr.Printf (" %s", input.GetStringAtIndex (i));
auto_generated_function.AppendString (sstr.GetData());
}
auto_generated_function.AppendString (" for key in new_keys:"); // Iterate over all the keys from session dict
<rdar://problem/11975483> Removing user-visible references to 'dict' as a parameter name for Python summary-generating functions since it is a Python keyword. llvm-svn: 161467
2012-08-08 02:06:30 +00:00
auto_generated_function.AppendString (" internal_dict[key] = global_dict[key]"); // Update session dict values
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
auto_generated_function.AppendString (" if key not in old_keys:"); // If key was not originally in global dict
auto_generated_function.AppendString (" del global_dict[key]"); // ...then remove key/value from global dict
// Verify that the results are valid Python.
if (!ExportFunctionDefinitionToInterpreter (auto_generated_function))
return false;
return true;
}
bool
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
ScriptInterpreterPython::GenerateTypeScriptFunction (StringList &user_input, std::string& output, void* name_token)
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
{
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
static uint32_t num_created_functions = 0;
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
user_input.RemoveBlankLines ();
StreamString sstr;
// Check to see if we have any data; if not, just return.
if (user_input.GetSize() == 0)
return false;
// Take what the user wrote, wrap it all up inside one big auto-generated Python function, passing in the
// ValueObject as parameter to the function.
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
std::string auto_generated_function_name(GenerateUniqueName("lldb_autogen_python_type_print_func", num_created_functions, name_token));
<rdar://problem/11975483> Removing user-visible references to 'dict' as a parameter name for Python summary-generating functions since it is a Python keyword. llvm-svn: 161467
2012-08-08 02:06:30 +00:00
sstr.Printf ("def %s (valobj, internal_dict):", auto_generated_function_name.c_str());
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
if (!GenerateFunction(sstr.GetData(), user_input))
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
return false;
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
// Store the name of the auto-generated function to be called.
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
output.assign(auto_generated_function_name);
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
return true;
}
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
bool
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
ScriptInterpreterPython::GenerateScriptAliasFunction (StringList &user_input, std::string &output)
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
{
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
static uint32_t num_created_functions = 0;
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
user_input.RemoveBlankLines ();
StreamString sstr;
// Check to see if we have any data; if not, just return.
if (user_input.GetSize() == 0)
return false;
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
std::string auto_generated_function_name(GenerateUniqueName("lldb_autogen_python_cmd_alias_func", num_created_functions));
<rdar://problem/11975483> Removing user-visible references to 'dict' as a parameter name for Python summary-generating functions since it is a Python keyword. llvm-svn: 161467
2012-08-08 02:06:30 +00:00
sstr.Printf ("def %s (debugger, args, result, internal_dict):", auto_generated_function_name.c_str());
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
if (!GenerateFunction(sstr.GetData(),user_input))
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
return false;
// Store the name of the auto-generated function to be called.
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
output.assign(auto_generated_function_name);
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
return true;
}
new flag -P to type synth add lets you type a Python class interactively added a final newline to fooSynthProvider.py new option to automatically save user input in InputReaderEZ checking for NULL pointers in several new places llvm-svn: 135916
2011-07-25 16:59:05 +00:00
bool
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
ScriptInterpreterPython::GenerateTypeSynthClass (StringList &user_input, std::string &output, void* name_token)
new flag -P to type synth add lets you type a Python class interactively added a final newline to fooSynthProvider.py new option to automatically save user input in InputReaderEZ checking for NULL pointers in several new places llvm-svn: 135916
2011-07-25 16:59:05 +00:00
{
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
static uint32_t num_created_classes = 0;
new flag -P to type synth add lets you type a Python class interactively added a final newline to fooSynthProvider.py new option to automatically save user input in InputReaderEZ checking for NULL pointers in several new places llvm-svn: 135916
2011-07-25 16:59:05 +00:00
user_input.RemoveBlankLines ();
int num_lines = user_input.GetSize ();
StreamString sstr;
// Check to see if we have any data; if not, just return.
if (user_input.GetSize() == 0)
return false;
// Wrap all user input into a Python class
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
std::string auto_generated_class_name(GenerateUniqueName("lldb_autogen_python_type_synth_class",num_created_classes,name_token));
new flag -P to type synth add lets you type a Python class interactively added a final newline to fooSynthProvider.py new option to automatically save user input in InputReaderEZ checking for NULL pointers in several new places llvm-svn: 135916
2011-07-25 16:59:05 +00:00
StringList auto_generated_class;
// Create the function name & definition string.
sstr.Printf ("class %s:", auto_generated_class_name.c_str());
auto_generated_class.AppendString (sstr.GetData());
// Wrap everything up inside the class, increasing the indentation.
for (int i = 0; i < num_lines; ++i)
{
sstr.Clear ();
sstr.Printf (" %s", user_input.GetStringAtIndex (i));
auto_generated_class.AppendString (sstr.GetData());
}
// Verify that the results are valid Python.
// (even though the method is ExportFunctionDefinitionToInterpreter, a class will actually be exported)
// (TODO: rename that method to ExportDefinitionToInterpreter)
if (!ExportFunctionDefinitionToInterpreter (auto_generated_class))
return false;
// Store the name of the auto-generated class
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
output.assign(auto_generated_class_name);
new flag -P to type synth add lets you type a Python class interactively added a final newline to fooSynthProvider.py new option to automatically save user input in InputReaderEZ checking for NULL pointers in several new places llvm-svn: 135916
2011-07-25 16:59:05 +00:00
return true;
}
Adding bindings to the Script Interpreter for some basic Python OS plugin functionality (still WIP) llvm-svn: 162513
2012-08-24 00:30:47 +00:00
lldb::ScriptInterpreterObjectSP
ScriptInterpreterPython::CreateOSPlugin (std::string class_name,
lldb::ProcessSP process_sp)
{
if (class_name.empty())
return lldb::ScriptInterpreterObjectSP();
if (!process_sp)
return lldb::ScriptInterpreterObjectSP();
void* ret_val;
{
Fixing a bunch of issues with the OS plugin code llvm-svn: 162527
2012-08-24 01:34:39 +00:00
Locker py_lock(this,Locker::AcquireLock,Locker::FreeLock);
Adding bindings to the Script Interpreter for some basic Python OS plugin functionality (still WIP) llvm-svn: 162513
2012-08-24 00:30:47 +00:00
ret_val = g_swig_create_os_plugin (class_name,
m_dictionary_name.c_str(),
process_sp);
}
return MakeScriptObject(ret_val);
}
lldb::ScriptInterpreterObjectSP
ScriptInterpreterPython::OSPlugin_QueryForRegisterInfo (lldb::ScriptInterpreterObjectSP object)
{
Fixing a bunch of issues with the OS plugin code llvm-svn: 162527
2012-08-24 01:34:39 +00:00
Locker py_lock(this,Locker::AcquireLock,Locker::FreeLock);
Adding bindings to the Script Interpreter for some basic Python OS plugin functionality (still WIP) llvm-svn: 162513
2012-08-24 00:30:47 +00:00
static char callee_name[] = "get_register_info";
if (!object)
return lldb::ScriptInterpreterObjectSP();
PyObject* implementor = (PyObject*)object->GetObject();
if (implementor == NULL || implementor == Py_None)
return lldb::ScriptInterpreterObjectSP();
PyObject* pmeth = PyObject_GetAttrString(implementor, callee_name);
if (PyErr_Occurred())
{
PyErr_Clear();
}
if (pmeth == NULL || pmeth == Py_None)
{
Py_XDECREF(pmeth);
return lldb::ScriptInterpreterObjectSP();
}
if (PyCallable_Check(pmeth) == 0)
{
if (PyErr_Occurred())
{
PyErr_Clear();
}
Py_XDECREF(pmeth);
return lldb::ScriptInterpreterObjectSP();
}
if (PyErr_Occurred())
{
PyErr_Clear();
}
Py_XDECREF(pmeth);
// right now we know this function exists and is callable..
PyObject* py_return = PyObject_CallMethod(implementor, callee_name, NULL);
// if it fails, print the error but otherwise go on
if (PyErr_Occurred())
{
PyErr_Print();
PyErr_Clear();
}
return MakeScriptObject(py_return);
}
Hooking up two more calls for the PythonOSPlugin stuff. The part of code to fetch the data and convert it to C++ objects is still missing, but will come llvm-svn: 162522
2012-08-24 00:51:29 +00:00
lldb::ScriptInterpreterObjectSP
ScriptInterpreterPython::OSPlugin_QueryForThreadsInfo (lldb::ScriptInterpreterObjectSP object)
{
Fixing a bunch of issues with the OS plugin code llvm-svn: 162527
2012-08-24 01:34:39 +00:00
Locker py_lock(this,Locker::AcquireLock,Locker::FreeLock);
Hooking up two more calls for the PythonOSPlugin stuff. The part of code to fetch the data and convert it to C++ objects is still missing, but will come llvm-svn: 162522
2012-08-24 00:51:29 +00:00
static char callee_name[] = "get_thread_info";
if (!object)
return lldb::ScriptInterpreterObjectSP();
PyObject* implementor = (PyObject*)object->GetObject();
if (implementor == NULL || implementor == Py_None)
return lldb::ScriptInterpreterObjectSP();
PyObject* pmeth = PyObject_GetAttrString(implementor, callee_name);
if (PyErr_Occurred())
{
PyErr_Clear();
}
if (pmeth == NULL || pmeth == Py_None)
{
Py_XDECREF(pmeth);
return lldb::ScriptInterpreterObjectSP();
}
if (PyCallable_Check(pmeth) == 0)
{
if (PyErr_Occurred())
{
PyErr_Clear();
}
Py_XDECREF(pmeth);
return lldb::ScriptInterpreterObjectSP();
}
if (PyErr_Occurred())
{
PyErr_Clear();
}
Py_XDECREF(pmeth);
// right now we know this function exists and is callable..
PyObject* py_return = PyObject_CallMethod(implementor, callee_name, NULL);
// if it fails, print the error but otherwise go on
if (PyErr_Occurred())
{
PyErr_Print();
PyErr_Clear();
}
return MakeScriptObject(py_return);
}
lldb::ScriptInterpreterObjectSP
The OS plug-in can now get data from a python script that implements the protocol. llvm-svn: 162540
2012-08-24 05:45:15 +00:00
ScriptInterpreterPython::OSPlugin_QueryForRegisterContextData (lldb::ScriptInterpreterObjectSP object,
lldb::tid_t thread_id)
Hooking up two more calls for the PythonOSPlugin stuff. The part of code to fetch the data and convert it to C++ objects is still missing, but will come llvm-svn: 162522
2012-08-24 00:51:29 +00:00
{
Fixing a bunch of issues with the OS plugin code llvm-svn: 162527
2012-08-24 01:34:39 +00:00
Locker py_lock(this,Locker::AcquireLock,Locker::FreeLock);
Hooking up two more calls for the PythonOSPlugin stuff. The part of code to fetch the data and convert it to C++ objects is still missing, but will come llvm-svn: 162522
2012-08-24 00:51:29 +00:00
static char callee_name[] = "get_register_data";
static char param_format[] = "l";
if (!object)
return lldb::ScriptInterpreterObjectSP();
PyObject* implementor = (PyObject*)object->GetObject();
if (implementor == NULL || implementor == Py_None)
return lldb::ScriptInterpreterObjectSP();
PyObject* pmeth = PyObject_GetAttrString(implementor, callee_name);
if (PyErr_Occurred())
{
PyErr_Clear();
}
if (pmeth == NULL || pmeth == Py_None)
{
Py_XDECREF(pmeth);
return lldb::ScriptInterpreterObjectSP();
}
if (PyCallable_Check(pmeth) == 0)
{
if (PyErr_Occurred())
{
PyErr_Clear();
}
Py_XDECREF(pmeth);
return lldb::ScriptInterpreterObjectSP();
}
if (PyErr_Occurred())
{
PyErr_Clear();
}
Py_XDECREF(pmeth);
// right now we know this function exists and is callable..
PyObject* py_return = PyObject_CallMethod(implementor, callee_name, param_format, thread_id);
// if it fails, print the error but otherwise go on
if (PyErr_Occurred())
{
PyErr_Print();
PyErr_Clear();
}
return MakeScriptObject(py_return);
}
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
lldb::ScriptInterpreterObjectSP
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
ScriptInterpreterPython::CreateSyntheticScriptedProvider (std::string class_name,
lldb::ValueObjectSP valobj)
{
if (class_name.empty())
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
return lldb::ScriptInterpreterObjectSP();
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
if (!valobj.get())
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
return lldb::ScriptInterpreterObjectSP();
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 07:49:44 +00:00
ExecutionContext exe_ctx (valobj->GetExecutionContextRef());
Target *target = exe_ctx.GetTargetPtr();
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
if (!target)
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
return lldb::ScriptInterpreterObjectSP();
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
Debugger &debugger = target->GetDebugger();
ScriptInterpreter *script_interpreter = debugger.GetCommandInterpreter().GetScriptInterpreter();
ScriptInterpreterPython *python_interpreter = (ScriptInterpreterPython *) script_interpreter;
if (!script_interpreter)
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
return lldb::ScriptInterpreterObjectSP();
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
void* ret_val;
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
{
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
Locker py_lock(this);
<rdar://problem/12437442> Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar* If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was no trivial way for us to change the SP inside an SBValue on the fly This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM) As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases) llvm-svn: 166426
2012-10-22 18:18:36 +00:00
ret_val = g_swig_synthetic_script (class_name,
python_interpreter->m_dictionary_name.c_str(),
valobj);
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
}
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
return MakeScriptObject(ret_val);
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
}
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
bool
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
ScriptInterpreterPython::GenerateTypeScriptFunction (const char* oneliner, std::string& output, void* name_token)
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
{
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 02:34:21 +00:00
StringList input;
input.SplitIntoLines(oneliner, strlen(oneliner));
return GenerateTypeScriptFunction(input, output, name_token);
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
}
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 02:34:21 +00:00
bool
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
ScriptInterpreterPython::GenerateTypeSynthClass (const char* oneliner, std::string& output, void* name_token)
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 02:34:21 +00:00
{
StringList input;
input.SplitIntoLines(oneliner, strlen(oneliner));
return GenerateTypeSynthClass(input, output, name_token);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
bool
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
ScriptInterpreterPython::GenerateBreakpointCommandCallbackData (StringList &user_input, std::string& output)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
{
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
static uint32_t num_created_functions = 0;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
user_input.RemoveBlankLines ();
Automatically wrap *all* Python code entered for a breakpoint command inside an auto-generated Python function, and pass the stoppoint context frame and breakpoint location as parameters to the function (named 'frame' and 'bp_loc'), to be used inside the breakpoint command Python code, if desired. llvm-svn: 114849
2010-09-27 18:00:20 +00:00
StreamString sstr;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
Add the ability to catch and do the right thing with Interrupts (often control-c) and end-of-file (often control-d). llvm-svn: 119837
2010-11-19 20:47:54 +00:00
if (user_input.GetSize() == 0)
return false;
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
std::string auto_generated_function_name(GenerateUniqueName("lldb_autogen_python_bp_callback_func_",num_created_functions));
<rdar://problem/11975483> Removing user-visible references to 'dict' as a parameter name for Python summary-generating functions since it is a Python keyword. llvm-svn: 161467
2012-08-08 02:06:30 +00:00
sstr.Printf ("def %s (frame, bp_loc, internal_dict):", auto_generated_function_name.c_str());
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
if (!GenerateFunction(sstr.GetData(), user_input))
Re-write/clean up code that generated Python breakpoint commands. Add a warning if no command was attached to the breakpoint. Update the help slightly. llvm-svn: 114467
2010-09-21 19:25:28 +00:00
return false;
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
Automatically wrap *all* Python code entered for a breakpoint command inside an auto-generated Python function, and pass the stoppoint context frame and breakpoint location as parameters to the function (named 'frame' and 'bp_loc'), to be used inside the breakpoint command Python code, if desired. llvm-svn: 114849
2010-09-27 18:00:20 +00:00
// Store the name of the auto-generated function to be called.
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
output.assign(auto_generated_function_name);
Automatically wrap *all* Python code entered for a breakpoint command inside an auto-generated Python function, and pass the stoppoint context frame and breakpoint location as parameters to the function (named 'frame' and 'bp_loc'), to be used inside the breakpoint command Python code, if desired. llvm-svn: 114849
2010-09-27 18:00:20 +00:00
return true;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
}
Automatically wrap *all* Python code entered for a breakpoint command inside an auto-generated Python function, and pass the stoppoint context frame and breakpoint location as parameters to the function (named 'frame' and 'bp_loc'), to be used inside the breakpoint command Python code, if desired. llvm-svn: 114849
2010-09-27 18:00:20 +00:00
rdar://problem/11457143 [ER] need "watchpoint command ..." Add 'watchpoint command add/delete/list' to lldb, plus two .py test files. llvm-svn: 161638
2012-08-09 23:09:42 +00:00
bool
ScriptInterpreterPython::GenerateWatchpointCommandCallbackData (StringList &user_input, std::string& output)
{
static uint32_t num_created_functions = 0;
user_input.RemoveBlankLines ();
StreamString sstr;
if (user_input.GetSize() == 0)
return false;
std::string auto_generated_function_name(GenerateUniqueName("lldb_autogen_python_wp_callback_func_",num_created_functions));
sstr.Printf ("def %s (frame, wp, internal_dict):", auto_generated_function_name.c_str());
if (!GenerateFunction(sstr.GetData(), user_input))
return false;
// Store the name of the auto-generated function to be called.
output.assign(auto_generated_function_name);
return true;
}
This commit: a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
2012-02-29 03:28:49 +00:00
bool
ScriptInterpreterPython::GetScriptedSummary (const char *python_function_name,
lldb::ValueObjectSP valobj,
lldb::ScriptInterpreterObjectSP& callee_wrapper_sp,
std::string& retval)
{
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
This commit: a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
2012-02-29 03:28:49 +00:00
Timer scoped_timer (__PRETTY_FUNCTION__, __PRETTY_FUNCTION__);
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
This commit: a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
2012-02-29 03:28:49 +00:00
if (!valobj.get())
{
retval.assign("<no object>");
return false;
}
void* old_callee = (callee_wrapper_sp ? callee_wrapper_sp->GetObject() : NULL);
void* new_callee = old_callee;
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
This commit: a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
2012-02-29 03:28:49 +00:00
bool ret_val;
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
if (python_function_name
&& *python_function_name)
{
{
This commit: a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
2012-02-29 03:28:49 +00:00
Locker py_lock(this);
{
Timer scoped_timer ("g_swig_typescript_callback","g_swig_typescript_callback");
ret_val = g_swig_typescript_callback (python_function_name,
FindSessionDictionary(m_dictionary_name.c_str()),
valobj,
&new_callee,
retval);
}
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
}
}
else
This commit: a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
2012-02-29 03:28:49 +00:00
{
retval.assign("<no function name>");
return false;
}
if (new_callee && old_callee != new_callee)
callee_wrapper_sp = MakeScriptObject(new_callee);
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 02:26:42 +00:00
return ret_val;
}
More SWIG cleanup. Moved the breakpoint callback function back to the ScriptInterpreterPython class and made a simple callback function that ScriptInterpreterPython::BreakpointCallbackFunction() now calls so we don't include any internal API stuff into the cpp file that is generated by SWIG. Fixed a few build warnings in debugserver. llvm-svn: 115926
2010-10-07 17:14:24 +00:00
bool
ScriptInterpreterPython::BreakpointCallbackFunction
(
void *baton,
StoppointCallbackContext *context,
user_id_t break_id,
user_id_t break_loc_id
)
{
BreakpointOptions::CommandData *bp_option_data = (BreakpointOptions::CommandData *) baton;
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
const char *python_function_name = bp_option_data->script_source.c_str();
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
if (!context)
return true;
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 00:09:25 +00:00
ExecutionContext exe_ctx (context->exe_ctx_ref);
Target *target = exe_ctx.GetTargetPtr();
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
if (!target)
return true;
Debugger &debugger = target->GetDebugger();
ScriptInterpreter *script_interpreter = debugger.GetCommandInterpreter().GetScriptInterpreter();
ScriptInterpreterPython *python_interpreter = (ScriptInterpreterPython *) script_interpreter;
if (!script_interpreter)
return true;
More SWIG cleanup. Moved the breakpoint callback function back to the ScriptInterpreterPython class and made a simple callback function that ScriptInterpreterPython::BreakpointCallbackFunction() now calls so we don't include any internal API stuff into the cpp file that is generated by SWIG. Fixed a few build warnings in debugserver. llvm-svn: 115926
2010-10-07 17:14:24 +00:00
if (python_function_name != NULL
&& python_function_name[0] != '\0')
{
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 00:09:25 +00:00
const StackFrameSP stop_frame_sp (exe_ctx.GetFrameSP());
More SWIG cleanup. Moved the breakpoint callback function back to the ScriptInterpreterPython class and made a simple callback function that ScriptInterpreterPython::BreakpointCallbackFunction() now calls so we don't include any internal API stuff into the cpp file that is generated by SWIG. Fixed a few build warnings in debugserver. llvm-svn: 115926
2010-10-07 17:14:24 +00:00
BreakpointSP breakpoint_sp = target->GetBreakpointByID (break_id);
Abtracted the innards of lldb-core away from the SB interface. There was some overlap in the SWIG integration which has now been fixed by introducing callbacks for initializing SWIG for each language (python only right now). There was also a breakpoint command callback that called into SWIG which has been abtracted into a callback to avoid cross over as well. Added a new binary: lldb-platform This will be the start of the remote platform that will use as much of the Host functionality to do its job so it should just work on all platforms. It is pretty hollowed out for now, but soon it will implement a platform using the GDB remote packets as the transport. llvm-svn: 128053
2011-03-22 01:14:58 +00:00
if (breakpoint_sp)
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
{
Abtracted the innards of lldb-core away from the SB interface. There was some overlap in the SWIG integration which has now been fixed by introducing callbacks for initializing SWIG for each language (python only right now). There was also a breakpoint command callback that called into SWIG which has been abtracted into a callback to avoid cross over as well. Added a new binary: lldb-platform This will be the start of the remote platform that will use as much of the Host functionality to do its job so it should just work on all platforms. It is pretty hollowed out for now, but soon it will implement a platform using the GDB remote packets as the transport. llvm-svn: 128053
2011-03-22 01:14:58 +00:00
const BreakpointLocationSP bp_loc_sp (breakpoint_sp->FindLocationByID (break_loc_id));
if (stop_frame_sp && bp_loc_sp)
Replace Mutex guarding python interpreter access with Predicate, allowing timeouts & informing the user when the lock is unavailable. Fixed problem where Debugger::Terminate was clearing the debugger list even when the global ref count was greater than zero. llvm-svn: 123674
2011-01-17 21:55:19 +00:00
{
Abtracted the innards of lldb-core away from the SB interface. There was some overlap in the SWIG integration which has now been fixed by introducing callbacks for initializing SWIG for each language (python only right now). There was also a breakpoint command callback that called into SWIG which has been abtracted into a callback to avoid cross over as well. Added a new binary: lldb-platform This will be the start of the remote platform that will use as much of the Host functionality to do its job so it should just work on all platforms. It is pretty hollowed out for now, but soon it will implement a platform using the GDB remote packets as the transport. llvm-svn: 128053
2011-03-22 01:14:58 +00:00
bool ret_val = true;
{
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
Locker py_lock(python_interpreter);
Abtracted the innards of lldb-core away from the SB interface. There was some overlap in the SWIG integration which has now been fixed by introducing callbacks for initializing SWIG for each language (python only right now). There was also a breakpoint command callback that called into SWIG which has been abtracted into a callback to avoid cross over as well. Added a new binary: lldb-platform This will be the start of the remote platform that will use as much of the Host functionality to do its job so it should just work on all platforms. It is pretty hollowed out for now, but soon it will implement a platform using the GDB remote packets as the transport. llvm-svn: 128053
2011-03-22 01:14:58 +00:00
ret_val = g_swig_breakpoint_callback (python_function_name,
python_interpreter->m_dictionary_name.c_str(),
stop_frame_sp,
bp_loc_sp);
}
return ret_val;
Replace Mutex guarding python interpreter access with Predicate, allowing timeouts & informing the user when the lock is unavailable. Fixed problem where Debugger::Terminate was clearing the debugger list even when the global ref count was greater than zero. llvm-svn: 123674
2011-01-17 21:55:19 +00:00
}
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
}
More SWIG cleanup. Moved the breakpoint callback function back to the ScriptInterpreterPython class and made a simple callback function that ScriptInterpreterPython::BreakpointCallbackFunction() now calls so we don't include any internal API stuff into the cpp file that is generated by SWIG. Fixed a few build warnings in debugserver. llvm-svn: 115926
2010-10-07 17:14:24 +00:00
}
// We currently always true so we stop in case anything goes wrong when
// trying to call the script function
return true;
}
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
rdar://problem/11457143 [ER] need "watchpoint command ..." Add 'watchpoint command add/delete/list' to lldb, plus two .py test files. llvm-svn: 161638
2012-08-09 23:09:42 +00:00
bool
ScriptInterpreterPython::WatchpointCallbackFunction
(
void *baton,
StoppointCallbackContext *context,
user_id_t watch_id
)
{
WatchpointOptions::CommandData *wp_option_data = (WatchpointOptions::CommandData *) baton;
const char *python_function_name = wp_option_data->script_source.c_str();
if (!context)
return true;
ExecutionContext exe_ctx (context->exe_ctx_ref);
Target *target = exe_ctx.GetTargetPtr();
if (!target)
return true;
Debugger &debugger = target->GetDebugger();
ScriptInterpreter *script_interpreter = debugger.GetCommandInterpreter().GetScriptInterpreter();
ScriptInterpreterPython *python_interpreter = (ScriptInterpreterPython *) script_interpreter;
if (!script_interpreter)
return true;
if (python_function_name != NULL
&& python_function_name[0] != '\0')
{
const StackFrameSP stop_frame_sp (exe_ctx.GetFrameSP());
WatchpointSP wp_sp = target->GetWatchpointList().FindByID (watch_id);
if (wp_sp)
{
if (stop_frame_sp && wp_sp)
{
bool ret_val = true;
{
Locker py_lock(python_interpreter);
ret_val = g_swig_watchpoint_callback (python_function_name,
python_interpreter->m_dictionary_name.c_str(),
stop_frame_sp,
wp_sp);
}
return ret_val;
}
}
}
// We currently always true so we stop in case anything goes wrong when
// trying to call the script function
return true;
}
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
lldb::thread_result_t
ScriptInterpreterPython::RunEmbeddedPythonInterpreter (lldb::thread_arg_t baton)
{
ScriptInterpreterPython *script_interpreter = (ScriptInterpreterPython *) baton;
LogSP log (lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_SCRIPT));
if (log)
log->Printf ("%p ScriptInterpreterPython::RunEmbeddedPythonInterpreter () thread starting...", baton);
char error_str[1024];
const char *pty_slave_name = script_interpreter->m_embedded_python_pty.GetSlaveName (error_str, sizeof (error_str));
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
if (pty_slave_name != NULL)
Replace Mutex guarding python interpreter access with Predicate, allowing timeouts & informing the user when the lock is unavailable. Fixed problem where Debugger::Terminate was clearing the debugger list even when the global ref count was greater than zero. llvm-svn: 123674
2011-01-17 21:55:19 +00:00
{
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
StreamString run_string;
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
// Ensure we have the GIL before running any Python code.
// Since we're only running a few one-liners and then dropping to the interpreter (which will release the GIL when needed),
// we can just release the GIL after finishing our work.
// If finer-grained locking is desirable, we can lock and unlock the GIL only when calling a python function.
Locker locker(script_interpreter,
ScriptInterpreterPython::Locker::AcquireLock | ScriptInterpreterPython::Locker::InitSession,
ScriptInterpreterPython::Locker::FreeAcquiredLock | ScriptInterpreterPython::Locker::TearDownSession);
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
run_string.Printf ("run_one_line (%s, 'save_stderr = sys.stderr')", script_interpreter->m_dictionary_name.c_str());
PyRun_SimpleString (run_string.GetData());
run_string.Clear ();
run_string.Printf ("run_one_line (%s, 'sys.stderr = sys.stdout')", script_interpreter->m_dictionary_name.c_str());
PyRun_SimpleString (run_string.GetData());
run_string.Clear ();
run_string.Printf ("run_one_line (%s, 'save_stdin = sys.stdin')", script_interpreter->m_dictionary_name.c_str());
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
PyRun_SimpleString (run_string.GetData());
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
run_string.Clear ();
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
run_string.Printf ("run_one_line (%s, \"sys.stdin = open ('%s', 'r')\")", script_interpreter->m_dictionary_name.c_str(),
pty_slave_name);
PyRun_SimpleString (run_string.GetData());
run_string.Clear ();
Minor typo fix and TAB removals. llvm-svn: 127439
2011-03-11 00:28:50 +00:00
// The following call drops into the embedded interpreter loop and stays there until the
// user chooses to exit from the Python interpreter.
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
// This embedded interpreter will, as any Python code that performs I/O, unlock the GIL before
// a system call that can hang, and lock it when the syscall has returned.
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
// We need to surround the call to the embedded interpreter with calls to PyGILState_Ensure and
// PyGILState_Release (using the Locker above). This is because Python has a global lock which must be held whenever we want
// to touch any Python objects. Otherwise, if the user calls Python code, the interpreter state will be off,
// and things could hang (it's happened before).
Add some explanatory comments. llvm-svn: 127438
2011-03-11 00:21:55 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
run_string.Printf ("run_python_interpreter (%s)", script_interpreter->m_dictionary_name.c_str());
PyRun_SimpleString (run_string.GetData());
run_string.Clear ();
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
run_string.Printf ("run_one_line (%s, 'sys.stdin = save_stdin')", script_interpreter->m_dictionary_name.c_str());
PyRun_SimpleString (run_string.GetData());
run_string.Clear();
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
run_string.Printf ("run_one_line (%s, 'sys.stderr = save_stderr')", script_interpreter->m_dictionary_name.c_str());
PyRun_SimpleString (run_string.GetData());
run_string.Clear();
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
}
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
if (script_interpreter->m_embedded_python_input_reader_sp)
script_interpreter->m_embedded_python_input_reader_sp->SetIsDone (true);
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
script_interpreter->m_embedded_python_pty.CloseSlaveFileDescriptor();
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
log = lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_SCRIPT);
if (log)
log->Printf ("%p ScriptInterpreterPython::RunEmbeddedPythonInterpreter () thread exiting...", baton);
Minor typo fix and TAB removals. llvm-svn: 127439
2011-03-11 00:28:50 +00:00
// Clean up the input reader and make the debugger pop it off the stack.
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Debugger &debugger = script_interpreter->GetCommandInterpreter().GetDebugger();
Fix a race condition where multiple PythonInputReaderManager instances could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
2012-08-17 23:44:35 +00:00
const InputReaderSP reader_sp = script_interpreter->m_embedded_python_input_reader_sp;
if (reader_sp)
{
debugger.PopInputReader (reader_sp);
script_interpreter->m_embedded_python_input_reader_sp.reset();
}
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
return NULL;
}
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
lldb::thread_result_t
ScriptInterpreterPython::PythonInputReaderManager::RunPythonInputReader (lldb::thread_arg_t baton)
{
ScriptInterpreterPython *script_interpreter = (ScriptInterpreterPython *) baton;
const InputReaderSP reader_sp = script_interpreter->m_embedded_thread_input_reader_sp;
if (reader_sp)
reader_sp->WaitOnReaderIsDone();
return NULL;
}
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
uint32_t
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
ScriptInterpreterPython::CalculateNumChildren (const lldb::ScriptInterpreterObjectSP& implementor_sp)
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
{
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
if (!implementor_sp)
return 0;
void* implementor = implementor_sp->GetObject();
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
if (!implementor)
return 0;
if (!g_swig_calc_children)
return 0;
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
uint32_t ret_val = 0;
{
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
Locker py_lock(this);
<rdar://problem/12437442> Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar* If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was no trivial way for us to change the SP inside an SBValue on the fly This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM) As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases) llvm-svn: 166426
2012-10-22 18:18:36 +00:00
ret_val = g_swig_calc_children (implementor);
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
}
return ret_val;
}
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-06 19:20:51 +00:00
lldb::ValueObjectSP
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
ScriptInterpreterPython::GetChildAtIndex (const lldb::ScriptInterpreterObjectSP& implementor_sp, uint32_t idx)
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
{
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
if (!implementor_sp)
return lldb::ValueObjectSP();
void* implementor = implementor_sp->GetObject();
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
if (!implementor)
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-06 19:20:51 +00:00
return lldb::ValueObjectSP();
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-06 19:20:51 +00:00
if (!g_swig_get_child_index || !g_swig_cast_to_sbvalue)
return lldb::ValueObjectSP();
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-06 19:20:51 +00:00
void* child_ptr = NULL;
lldb::SBValue* value_sb = NULL;
lldb::ValueObjectSP ret_val;
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
{
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
Locker py_lock(this);
<rdar://problem/12437442> Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar* If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was no trivial way for us to change the SP inside an SBValue on the fly This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM) As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases) llvm-svn: 166426
2012-10-22 18:18:36 +00:00
child_ptr = g_swig_get_child_index (implementor,idx);
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-06 19:20:51 +00:00
if (child_ptr != NULL && child_ptr != Py_None)
{
value_sb = (lldb::SBValue*)g_swig_cast_to_sbvalue(child_ptr);
if (value_sb == NULL)
Py_XDECREF(child_ptr);
else
ret_val = value_sb->get_sp();
}
else
{
Py_XDECREF(child_ptr);
}
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
}
return ret_val;
}
int
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
ScriptInterpreterPython::GetIndexOfChildWithName (const lldb::ScriptInterpreterObjectSP& implementor_sp, const char* child_name)
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
{
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
if (!implementor_sp)
return UINT32_MAX;
void* implementor = implementor_sp->GetObject();
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
if (!implementor)
return UINT32_MAX;
if (!g_swig_get_index_child)
return UINT32_MAX;
int ret_val = UINT32_MAX;
{
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
Locker py_lock(this);
<rdar://problem/12437442> Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar* If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was no trivial way for us to change the SP inside an SBValue on the fly This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM) As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases) llvm-svn: 166426
2012-10-22 18:18:36 +00:00
ret_val = g_swig_get_index_child (implementor, child_name);
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference llvm-svn: 135865
2011-07-24 00:14:56 +00:00
}
return ret_val;
}
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-19 22:58:49 +00:00
bool
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
ScriptInterpreterPython::UpdateSynthProviderInstance (const lldb::ScriptInterpreterObjectSP& implementor_sp)
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-29 19:53:35 +00:00
{
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-19 22:58:49 +00:00
bool ret_val = false;
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
if (!implementor_sp)
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-19 22:58:49 +00:00
return ret_val;
Using the new ScriptInterpreterObject in the implementation of synthetic children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
2012-03-06 23:42:15 +00:00
void* implementor = implementor_sp->GetObject();
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-29 19:53:35 +00:00
if (!implementor)
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-19 22:58:49 +00:00
return ret_val;
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-29 19:53:35 +00:00
if (!g_swig_update_provider)
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-19 22:58:49 +00:00
return ret_val;
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-29 19:53:35 +00:00
{
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
Locker py_lock(this);
<rdar://problem/12437442> Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar* If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was no trivial way for us to change the SP inside an SBValue on the fly This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM) As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases) llvm-svn: 166426
2012-10-22 18:18:36 +00:00
ret_val = g_swig_update_provider (implementor);
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-29 19:53:35 +00:00
}
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-19 22:58:49 +00:00
return ret_val;
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-29 19:53:35 +00:00
}
<rdar://problem/12523238> Commit 1 of 3 This commit enables the new HasChildren() feature for synthetic children providers Namely, it hooks up the required bits and pieces so that individual synthetic children providers can implement a new (optional) has_children call Default implementations have been provided where necessary so that any existing providers continue to work and behave correctly Next steps are: 2) writing smart implementations of has_children for our providers whenever possible 3) make a test case llvm-svn: 166495
2012-10-23 19:54:09 +00:00
bool
ScriptInterpreterPython::MightHaveChildrenSynthProviderInstance (const lldb::ScriptInterpreterObjectSP& implementor_sp)
{
bool ret_val = false;
if (!implementor_sp)
return ret_val;
void* implementor = implementor_sp->GetObject();
if (!implementor)
return ret_val;
if (!g_swig_mighthavechildren_provider)
return ret_val;
{
Locker py_lock(this);
ret_val = g_swig_mighthavechildren_provider (implementor);
}
return ret_val;
}
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
bool
ScriptInterpreterPython::LoadScriptingModule (const char* pathname,
this patch addresses several issues with "command script" subcommands: a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled) b) clears up several error messages c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before d) allows filename completion for "command script import" (much like what happens for "target create") e) prevents "command script add" from replacing built-in commands with scripted commands f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons) plus, it fixes an issue in "type summary add" command handling which caused several test suite errors llvm-svn: 144035
2011-11-07 22:57:04 +00:00
bool can_reload,
<rdar://problem/12491420> Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting: settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py Then run your program and see the extra threads. llvm-svn: 166244
2012-10-18 22:40:37 +00:00
bool init_lldb_globals,
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
lldb_private::Error& error)
{
if (!pathname || !pathname[0])
{
error.SetErrorString("invalid pathname");
return false;
}
if (!g_swig_call_module_init)
{
error.SetErrorString("internal helper function missing");
return false;
}
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2012-01-29 20:56:30 +00:00
lldb::DebuggerSP debugger_sp = m_interpreter.GetDebugger().shared_from_this();
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
{
FileSpec target_file(pathname, true);
// TODO: would we want to reject any other value?
if (target_file.GetFileType() == FileSpec::eFileTypeInvalid ||
target_file.GetFileType() == FileSpec::eFileTypeUnknown)
{
error.SetErrorString("invalid pathname");
return false;
}
const char* directory = target_file.GetDirectory().GetCString();
std::string basename(target_file.GetFilename().GetCString());
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
// Before executing Pyton code, lock the GIL.
<rdar://problem/12491420> Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting: settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py Then run your program and see the extra threads. llvm-svn: 166244
2012-10-18 22:40:37 +00:00
Locker py_lock (this,
Locker::AcquireLock | (init_lldb_globals ? Locker::InitSession : 0),
Locker::FreeAcquiredLock | (init_lldb_globals ? Locker::TearDownSession : 0));
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
// now make sure that Python has "directory" in the search path
StreamString command_stream;
command_stream.Printf("if not (sys.path.__contains__('%s')):\n sys.path.append('%s');\n\n",
directory,
directory);
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
bool syspath_retval = ExecuteMultipleLines(command_stream.GetData(), ScriptInterpreter::ExecuteScriptOptions().SetEnableIO(false).SetSetLLDBGlobals(false));
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
if (!syspath_retval)
{
error.SetErrorString("Python sys.path handling failed");
return false;
}
// strip .py or .pyc extension
ConstString extension = target_file.GetFileNameExtension();
if (::strcmp(extension.GetCString(), "py") == 0)
basename.resize(basename.length()-3);
else if(::strcmp(extension.GetCString(), "pyc") == 0)
basename.resize(basename.length()-4);
// check if the module is already import-ed
command_stream.Clear();
command_stream.Printf("sys.getrefcount(%s)",basename.c_str());
int refcount = 0;
// this call will fail if the module does not exist (because the parameter to it is not a string
// but an actual Python module object, which is non-existant if the module was not imported before)
this patch addresses several issues with "command script" subcommands: a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled) b) clears up several error messages c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before d) allows filename completion for "command script import" (much like what happens for "target create") e) prevents "command script add" from replacing built-in commands with scripted commands f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons) plus, it fixes an issue in "type summary add" command handling which caused several test suite errors llvm-svn: 144035
2011-11-07 22:57:04 +00:00
bool was_imported = (ExecuteOneLineWithReturn(command_stream.GetData(),
<rdar://problem/12491420> Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting: settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py Then run your program and see the extra threads. llvm-svn: 166244
2012-10-18 22:40:37 +00:00
ScriptInterpreterPython::eScriptReturnTypeInt,
&refcount,
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
ScriptInterpreter::ExecuteScriptOptions().SetEnableIO(false).SetSetLLDBGlobals(false)) && refcount > 0);
this patch addresses several issues with "command script" subcommands: a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled) b) clears up several error messages c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before d) allows filename completion for "command script import" (much like what happens for "target create") e) prevents "command script add" from replacing built-in commands with scripted commands f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons) plus, it fixes an issue in "type summary add" command handling which caused several test suite errors llvm-svn: 144035
2011-11-07 22:57:04 +00:00
if (was_imported == true && can_reload == false)
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
{
error.SetErrorString("module already imported");
return false;
}
// now actually do the import
command_stream.Clear();
command_stream.Printf("import %s",basename.c_str());
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
bool import_retval = ExecuteMultipleLines(command_stream.GetData(), ScriptInterpreter::ExecuteScriptOptions().SetEnableIO(false).SetSetLLDBGlobals(false).SetMaskoutErrors(false));
PyObject* py_error = PyErr_Occurred(); // per Python docs: "you do not need to Py_DECREF()" the return of this function
if (py_error || !import_retval) // check for failure of the import
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
{
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
if (py_error) // if we have a Python error..
{
if (PyErr_GivenExceptionMatches (py_error, PyExc_ImportError)) // and it is an ImportError
{
PyObject *type,*value,*traceback;
PyErr_Fetch (&type,&value,&traceback);
if (value && value != Py_None)
error.SetErrorString(PyString_AsString(PyObject_Str(value)));
else
error.SetErrorString("ImportError raised by imported module");
Py_XDECREF(type);
Py_XDECREF(value);
Py_XDECREF(traceback);
}
else // any other error
{
error.SetErrorString("Python raised an error while importing module");
}
}
else // we failed but have no error to explain why
{
error.SetErrorString("unknown error while importing module");
}
// anyway, clear the error indicator and return false
PyErr_Clear();
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
return false;
}
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
// if we are here, everything worked
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 02:34:21 +00:00
// call __lldb_init_module(debugger,dict)
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
if (!g_swig_call_module_init (basename,
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
m_dictionary_name.c_str(),
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
debugger_sp))
{
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 02:34:21 +00:00
error.SetErrorString("calling __lldb_init_module failed");
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
return false;
}
return true;
}
}
This commit: a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
2012-02-29 03:28:49 +00:00
lldb::ScriptInterpreterObjectSP
ScriptInterpreterPython::MakeScriptObject (void* object)
{
return lldb::ScriptInterpreterObjectSP(new ScriptInterpreterPythonObject(object));
}
this patch addresses several issues with "command script" subcommands: a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled) b) clears up several error messages c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before d) allows filename completion for "command script import" (much like what happens for "target create") e) prevents "command script add" from replacing built-in commands with scripted commands f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons) plus, it fixes an issue in "type summary add" command handling which caused several test suite errors llvm-svn: 144035
2011-11-07 22:57:04 +00:00
ScriptInterpreterPython::SynchronicityHandler::SynchronicityHandler (lldb::DebuggerSP debugger_sp,
ScriptedCommandSynchronicity synchro) :
m_debugger_sp(debugger_sp),
m_synch_wanted(synchro),
m_old_asynch(debugger_sp->GetAsyncExecution())
{
if (m_synch_wanted == eScriptedCommandSynchronicitySynchronous)
m_debugger_sp->SetAsyncExecution(false);
else if (m_synch_wanted == eScriptedCommandSynchronicityAsynchronous)
m_debugger_sp->SetAsyncExecution(true);
}
ScriptInterpreterPython::SynchronicityHandler::~SynchronicityHandler()
{
if (m_synch_wanted != eScriptedCommandSynchronicityCurrentValue)
m_debugger_sp->SetAsyncExecution(m_old_asynch);
}
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
bool
ScriptInterpreterPython::RunScriptBasedCommand(const char* impl_function,
const char* args,
this patch addresses several issues with "command script" subcommands: a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled) b) clears up several error messages c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before d) allows filename completion for "command script import" (much like what happens for "target create") e) prevents "command script add" from replacing built-in commands with scripted commands f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons) plus, it fixes an issue in "type summary add" command handling which caused several test suite errors llvm-svn: 144035
2011-11-07 22:57:04 +00:00
ScriptedCommandSynchronicity synchronicity,
Changes to Python commands: - They now have an SBCommandReturnObject instead of an SBStream as third argument - The class CommandObjectPythonFunction has been merged into CommandObjectCommands.cpp - The command to manage them is now: command script with subcommands add, list, delete, clear command alias is returned to its previous functionality - Python commands are now part of an user dictionary, instead of being seen as aliases llvm-svn: 137785
2011-08-16 23:24:13 +00:00
lldb_private::CommandReturnObject& cmd_retobj,
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
Error& error)
{
if (!impl_function)
{
error.SetErrorString("no function to execute");
return false;
}
if (!g_swig_call_command)
{
error.SetErrorString("no helper function to run scripted commands");
return false;
}
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2012-01-29 20:56:30 +00:00
lldb::DebuggerSP debugger_sp = m_interpreter.GetDebugger().shared_from_this();
this patch addresses several issues with "command script" subcommands: a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled) b) clears up several error messages c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before d) allows filename completion for "command script import" (much like what happens for "target create") e) prevents "command script add" from replacing built-in commands with scripted commands f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons) plus, it fixes an issue in "type summary add" command handling which caused several test suite errors llvm-svn: 144035
2011-11-07 22:57:04 +00:00
if (!debugger_sp.get())
{
error.SetErrorString("invalid Debugger pointer");
return false;
}
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
bool ret_val;
std::string err_msg;
this patch addresses several issues with "command script" subcommands: a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled) b) clears up several error messages c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before d) allows filename completion for "command script import" (much like what happens for "target create") e) prevents "command script add" from replacing built-in commands with scripted commands f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons) plus, it fixes an issue in "type summary add" command handling which caused several test suite errors llvm-svn: 144035
2011-11-07 22:57:04 +00:00
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
{
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
Locker py_lock(this);
this patch addresses several issues with "command script" subcommands: a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled) b) clears up several error messages c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before d) allows filename completion for "command script import" (much like what happens for "target create") e) prevents "command script add" from replacing built-in commands with scripted commands f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons) plus, it fixes an issue in "type summary add" command handling which caused several test suite errors llvm-svn: 144035
2011-11-07 22:57:04 +00:00
SynchronicityHandler synch_handler(debugger_sp,
synchronicity);
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows llvm-svn: 158124
2012-06-07 00:17:18 +00:00
PythonInputReaderManager py_input(this);
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
ret_val = g_swig_call_command (impl_function,
Decoupling of lock-related code from the core of ScriptInterpreterPython. All that concerns locking the Python interpreter is now delegated to the internal ScriptInterpreterPython::Locker class. Several changes in ScriptInterpreterPython to accommodate this new pattern. llvm-svn: 142802
2011-10-24 17:22:21 +00:00
m_dictionary_name.c_str(),
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
debugger_sp,
args,
err_msg,
Fixed some SWIG interoperability issues llvm-svn: 138154
2011-08-19 23:56:34 +00:00
cmd_retobj);
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
}
this patch addresses several issues with "command script" subcommands: a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled) b) clears up several error messages c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before d) allows filename completion for "command script import" (much like what happens for "target create") e) prevents "command script add" from replacing built-in commands with scripted commands f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons) plus, it fixes an issue in "type summary add" command handling which caused several test suite errors llvm-svn: 144035
2011-11-07 22:57:04 +00:00
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
if (!ret_val)
error.SetErrorString(err_msg.c_str());
else
error.Clear();
this patch addresses several issues with "command script" subcommands: a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled) b) clears up several error messages c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before d) allows filename completion for "command script import" (much like what happens for "target create") e) prevents "command script add" from replacing built-in commands with scripted commands f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons) plus, it fixes an issue in "type summary add" command handling which caused several test suite errors llvm-svn: 144035
2011-11-07 22:57:04 +00:00
return ret_val;
Python commands: It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
2011-08-16 16:49:25 +00:00
}
When defining a scripted command, it is possible to provide a docstring and that will be used as the help text for the command If no docstring is provided, a default help text is created LLDB will refuse to create scripted commands if the scripting language is anything but Python Some additional comments in AppleObjCRuntimeV2.cpp to describe the memory layout expected by the dynamic type lookup code llvm-svn: 137801
2011-08-17 01:30:04 +00:00
// in Python, a special attribute __doc__ contains the docstring
// for an object (function, method, class, ...) if any is defined
// Otherwise, the attribute's value is None
<rdar://problem/12188843> Fixing a problem where a Python command created in the same module where the target function is defined causes the help string not to come out llvm-svn: 164172
2012-09-18 21:53:02 +00:00
bool
ScriptInterpreterPython::GetDocumentationForItem(const char* item, std::string& dest)
When defining a scripted command, it is possible to provide a docstring and that will be used as the help text for the command If no docstring is provided, a default help text is created LLDB will refuse to create scripted commands if the scripting language is anything but Python Some additional comments in AppleObjCRuntimeV2.cpp to describe the memory layout expected by the dynamic type lookup code llvm-svn: 137801
2011-08-17 01:30:04 +00:00
{
<rdar://problem/12188843> Fixing a problem where a Python command created in the same module where the target function is defined causes the help string not to come out llvm-svn: 164172
2012-09-18 21:53:02 +00:00
dest.clear();
if (!item || !*item)
return false;
When defining a scripted command, it is possible to provide a docstring and that will be used as the help text for the command If no docstring is provided, a default help text is created LLDB will refuse to create scripted commands if the scripting language is anything but Python Some additional comments in AppleObjCRuntimeV2.cpp to describe the memory layout expected by the dynamic type lookup code llvm-svn: 137801
2011-08-17 01:30:04 +00:00
std::string command(item);
command += ".__doc__";
char* result_ptr = NULL; // Python is going to point this to valid data if ExecuteOneLineWithReturn returns successfully
if (ExecuteOneLineWithReturn (command.c_str(),
this patch introduces a new command script import command which takes as input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
2011-10-17 21:45:27 +00:00
ScriptInterpreter::eScriptReturnTypeCharStrOrNone,
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
2012-10-31 00:01:26 +00:00
&result_ptr, ScriptInterpreter::ExecuteScriptOptions().SetEnableIO(false) /*.SetSetLLDBGlobals(false)*/))
When defining a scripted command, it is possible to provide a docstring and that will be used as the help text for the command If no docstring is provided, a default help text is created LLDB will refuse to create scripted commands if the scripting language is anything but Python Some additional comments in AppleObjCRuntimeV2.cpp to describe the memory layout expected by the dynamic type lookup code llvm-svn: 137801
2011-08-17 01:30:04 +00:00
{
Fixing a logic error where we would incorrectly show the newly crafted function not found error for a Python function in some cases where the function actually existed and had an empty docstring llvm-svn: 164334
2012-09-20 23:23:55 +00:00
if (result_ptr)
dest.assign(result_ptr);
<rdar://problem/12188843> Fixing a problem where a Python command created in the same module where the target function is defined causes the help string not to come out llvm-svn: 164172
2012-09-18 21:53:02 +00:00
return true;
When defining a scripted command, it is possible to provide a docstring and that will be used as the help text for the command If no docstring is provided, a default help text is created LLDB will refuse to create scripted commands if the scripting language is anything but Python Some additional comments in AppleObjCRuntimeV2.cpp to describe the memory layout expected by the dynamic type lookup code llvm-svn: 137801
2011-08-17 01:30:04 +00:00
}
else
<rdar://problem/12188843> Fixing a problem where a Python command created in the same module where the target function is defined causes the help string not to come out llvm-svn: 164172
2012-09-18 21:53:02 +00:00
{
StreamString str_stream;
str_stream.Printf("Function %s was not found. Containing module might be missing.",item);
dest.assign(str_stream.GetData());
return false;
}
When defining a scripted command, it is possible to provide a docstring and that will be used as the help text for the command If no docstring is provided, a default help text is created LLDB will refuse to create scripted commands if the scripting language is anything but Python Some additional comments in AppleObjCRuntimeV2.cpp to describe the memory layout expected by the dynamic type lookup code llvm-svn: 137801
2011-08-17 01:30:04 +00:00
}
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
void
This commit: a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
2012-02-29 03:28:49 +00:00
ScriptInterpreterPython::InitializeInterpreter (SWIGInitCallback python_swig_init_callback)
Abtracted the innards of lldb-core away from the SB interface. There was some overlap in the SWIG integration which has now been fixed by introducing callbacks for initializing SWIG for each language (python only right now). There was also a breakpoint command callback that called into SWIG which has been abtracted into a callback to avoid cross over as well. Added a new binary: lldb-platform This will be the start of the remote platform that will use as much of the Host functionality to do its job so it should just work on all platforms. It is pretty hollowed out for now, but soon it will implement a platform using the GDB remote packets as the transport. llvm-svn: 128053
2011-03-22 01:14:58 +00:00
{
g_swig_init_callback = python_swig_init_callback;
This commit: a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
2012-02-29 03:28:49 +00:00
g_swig_breakpoint_callback = LLDBSwigPythonBreakpointCallbackFunction;
rdar://problem/11457143 [ER] need "watchpoint command ..." Add 'watchpoint command add/delete/list' to lldb, plus two .py test files. llvm-svn: 161638
2012-08-09 23:09:42 +00:00
g_swig_watchpoint_callback = LLDBSwigPythonWatchpointCallbackFunction;
This commit: a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
2012-02-29 03:28:49 +00:00
g_swig_typescript_callback = LLDBSwigPythonCallTypeScript;
g_swig_synthetic_script = LLDBSwigPythonCreateSyntheticProvider;
g_swig_calc_children = LLDBSwigPython_CalculateNumChildren;
g_swig_get_child_index = LLDBSwigPython_GetChildAtIndex;
g_swig_get_index_child = LLDBSwigPython_GetIndexOfChildWithName;
g_swig_cast_to_sbvalue = LLDBSWIGPython_CastPyObjectToSBValue;
g_swig_update_provider = LLDBSwigPython_UpdateSynthProviderInstance;
<rdar://problem/12523238> Commit 1 of 3 This commit enables the new HasChildren() feature for synthetic children providers Namely, it hooks up the required bits and pieces so that individual synthetic children providers can implement a new (optional) has_children call Default implementations have been provided where necessary so that any existing providers continue to work and behave correctly Next steps are: 2) writing smart implementations of has_children for our providers whenever possible 3) make a test case llvm-svn: 166495
2012-10-23 19:54:09 +00:00
g_swig_mighthavechildren_provider = LLDBSwigPython_MightHaveChildrenSynthProviderInstance;
This commit: a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
2012-02-29 03:28:49 +00:00
g_swig_call_command = LLDBSwigPythonCallCommand;
g_swig_call_module_init = LLDBSwigPythonCallModuleInit;
Adding bindings to the Script Interpreter for some basic Python OS plugin functionality (still WIP) llvm-svn: 162513
2012-08-24 00:30:47 +00:00
g_swig_create_os_plugin = LLDBSWIGPythonCreateOSPlugin;
Abtracted the innards of lldb-core away from the SB interface. There was some overlap in the SWIG integration which has now been fixed by introducing callbacks for initializing SWIG for each language (python only right now). There was also a breakpoint command callback that called into SWIG which has been abtracted into a callback to avoid cross over as well. Added a new binary: lldb-platform This will be the start of the remote platform that will use as much of the Host functionality to do its job so it should just work on all platforms. It is pretty hollowed out for now, but soon it will implement a platform using the GDB remote packets as the transport. llvm-svn: 128053
2011-03-22 01:14:58 +00:00
}
void
ScriptInterpreterPython::InitializePrivate ()
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
{
Timer scoped_timer (__PRETTY_FUNCTION__, __PRETTY_FUNCTION__);
Abtract terminal stuff into a new lldb_private::Terminal class where the implementation is hidden in the host layer. This avoids a slew of "#if LLDB_CONFIG_TERMIOS_SUPPORTED" statements in the code and keeps things cleaner. llvm-svn: 125057
2011-02-07 23:24:47 +00:00
// Python will muck with STDIN terminal state, so save off any current TTY
// settings so we can restore them.
TerminalState stdin_tty_state;
stdin_tty_state.Save(STDIN_FILENO, false);
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
PyGILState_STATE gstate;
LogSP log (lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_SCRIPT | LIBLLDB_LOG_VERBOSE));
bool threads_already_initialized = false;
if (PyEval_ThreadsInitialized ()) {
gstate = PyGILState_Ensure ();
if (log)
log->Printf("Ensured PyGILState. Previous state = %slocked\n", gstate == PyGILState_UNLOCKED ? "un" : "");
threads_already_initialized = true;
} else {
// InitThreads acquires the GIL if it hasn't been called before.
PyEval_InitThreads ();
}
Don't change the host's environment, just append our Python Directory directly to the one in sys. llvm-svn: 138693
2011-08-27 01:24:08 +00:00
Py_InitializeEx (0);
// Initialize SWIG after setting up python
assert (g_swig_init_callback != NULL);
g_swig_init_callback ();
// Update the path python uses to search for modules to include the current directory.
PyRun_SimpleString ("import sys");
PyRun_SimpleString ("sys.path.append ('.')");
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
// Find the module that owns this code and use that path we get to
Don't change the host's environment, just append our Python Directory directly to the one in sys. llvm-svn: 138693
2011-08-27 01:24:08 +00:00
// set the sys.path appropriately.
Move the embedded Python interpreter onto a separate thread, to prevent main thread from having to wait on it (which was causing some I/O hangs). llvm-svn: 118700
2010-11-10 19:18:14 +00:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
FileSpec file_spec;
char python_dir_path[PATH_MAX];
if (Host::GetLLDBPath (ePathTypePythonDir, file_spec))
{
Don't change the host's environment, just append our Python Directory directly to the one in sys. llvm-svn: 138693
2011-08-27 01:24:08 +00:00
std::string python_path("sys.path.insert(0,\"");
size_t orig_len = python_path.length();
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
if (file_spec.GetPath(python_dir_path, sizeof (python_dir_path)))
{
python_path.append (python_dir_path);
Don't change the host's environment, just append our Python Directory directly to the one in sys. llvm-svn: 138693
2011-08-27 01:24:08 +00:00
python_path.append ("\")");
PyRun_SimpleString (python_path.c_str());
python_path.resize (orig_len);
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
}
if (Host::GetLLDBPath (ePathTypeLLDBShlibDir, file_spec))
{
if (file_spec.GetPath(python_dir_path, sizeof (python_dir_path)))
{
python_path.append (python_dir_path);
Don't change the host's environment, just append our Python Directory directly to the one in sys. llvm-svn: 138693
2011-08-27 01:24:08 +00:00
python_path.append ("\")");
PyRun_SimpleString (python_path.c_str());
python_path.resize (orig_len);
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
}
}
}
Maked LLDB into a package so we can import things without poluting the global namespace. Enrico will follow this up with fixing the data formatter test cases that are failing. llvm-svn: 155514
2012-04-25 00:58:03 +00:00
PyRun_SimpleString ("sys.dont_write_bytecode = 1; import lldb.embedded_interpreter; from lldb.embedded_interpreter import run_python_interpreter; from lldb.embedded_interpreter import run_one_line; from termios import *");
More termios fixes from Kirk Beitz. llvm-svn: 125024
2011-02-07 19:04:58 +00:00
Merge python-GIL bracnh (by filcab) back into trunk! llvm-svn: 162161
2012-08-18 04:14:54 +00:00
if (threads_already_initialized) {
if (log)
log->Printf("Releasing PyGILState. Returning to state = %slocked\n", gstate == PyGILState_UNLOCKED ? "un" : "");
PyGILState_Release (gstate);
} else {
// We initialized the threads in this function, just unlock the GIL.
PyEval_SaveThread();
}
Abtract terminal stuff into a new lldb_private::Terminal class where the implementation is hidden in the host layer. This avoids a slew of "#if LLDB_CONFIG_TERMIOS_SUPPORTED" statements in the code and keeps things cleaner. llvm-svn: 125057
2011-02-07 23:24:47 +00:00
stdin_tty_state.Restore();
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 00:29:16 +00:00
}
Abtracted the innards of lldb-core away from the SB interface. There was some overlap in the SWIG integration which has now been fixed by introducing callbacks for initializing SWIG for each language (python only right now). There was also a breakpoint command callback that called into SWIG which has been abtracted into a callback to avoid cross over as well. Added a new binary: lldb-platform This will be the start of the remote platform that will use as much of the Host functionality to do its job so it should just work on all platforms. It is pretty hollowed out for now, but soon it will implement a platform using the GDB remote packets as the transport. llvm-svn: 128053
2011-03-22 01:14:58 +00:00
//void
//ScriptInterpreterPython::Terminate ()
//{
// // We are intentionally NOT calling Py_Finalize here (this would be the logical place to call it). Calling
// // Py_Finalize here causes test suite runs to seg fault: The test suite runs in Python. It registers
// // SBDebugger::Terminate to be called 'at_exit'. When the test suite Python harness finishes up, it calls
// // Py_Finalize, which calls all the 'at_exit' registered functions. SBDebugger::Terminate calls Debugger::Terminate,
// // which calls lldb::Terminate, which calls ScriptInterpreter::Terminate, which calls
// // ScriptInterpreterPython::Terminate. So if we call Py_Finalize here, we end up with Py_Finalize being called from
// // within Py_Finalize, which results in a seg fault.
// //
// // Since this function only gets called when lldb is shutting down and going away anyway, the fact that we don't
// // actually call Py_Finalize should not cause any problems (everything should shut down/go away anyway when the
// // process exits).
// //
//// Py_Finalize ();
//}
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 03:34:56 +00:00
#endif // #ifdef LLDB_DISABLE_PYTHON
Reference in New Issue Copy Permalink