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

167 lines
7.1 KiB
C++
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//===-- ScriptInterpreter.cpp -----------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
Fix Linux build warnings due to redefinition of macros: - add new header lldb-python.h to be included before other system headers - short term fix (eventually python dependencies must be cleaned up) Patch by Matt Kopec! llvm-svn: 169341
2012-12-05 08:20:57 +08:00
#include "lldb/lldb-python.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Interpreter/ScriptInterpreter.h"
#include <string>
#include <stdlib.h>
#include <stdio.h>
#include "lldb/Core/Error.h"
#include "lldb/Core/Stream.h"
#include "lldb/Core/StringList.h"
#include "lldb/Interpreter/CommandReturnObject.h"
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 08:29:16 +08:00
#include "lldb/Interpreter/ScriptInterpreterPython.h"
Move source/Utility/PseudoTerminal.h into include/lldb/Utility. The top of the header file seems to indicate that this was intended to be over at include/lldb/Core but we should be in line with the .cpp file's location so it's include/lldb/Utility for now. llvm-svn: 105753
2010-06-10 05:28:42 +08:00
#include "lldb/Utility/PseudoTerminal.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
using namespace lldb;
using namespace lldb_private;
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 08:29:16 +08:00
ScriptInterpreter::ScriptInterpreter (CommandInterpreter &interpreter, lldb::ScriptLanguage script_lang) :
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 09:14:36 +08:00
m_interpreter (interpreter),
<rdar://problem/10750012> Remove a pseudo terminal master open and slave file descriptor that was being used for pythong stdin. It was not hooked up correctly and was causing file descriptor leaks. llvm-svn: 149098
2012-01-27 08:13:27 +08:00
m_script_lang (script_lang)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
}
ScriptInterpreter::~ScriptInterpreter ()
{
}
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 08:29:16 +08:00
CommandInterpreter &
ScriptInterpreter::GetCommandInterpreter ()
{
return m_interpreter;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
ScriptInterpreter::CollectDataForBreakpointCommandCallback
(
Allow "breakpoint command add" to add commands to more than one breakpoint at a time. <rdar://problem/13314462> llvm-svn: 216747
2014-08-30 01:34:17 +08:00
std::vector<BreakpointOptions *> &bp_options_vec,
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
CommandReturnObject &result
)
{
result.SetStatus (eReturnStatusFailed);
result.AppendError ("ScriptInterpreter::GetScriptCommands(StringList &) is not implemented.");
}
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-10 07:09:42 +08:00
void
ScriptInterpreter::CollectDataForWatchpointCommandCallback
(
WatchpointOptions *bp_options,
CommandReturnObject &result
)
{
result.SetStatus (eReturnStatusFailed);
result.AppendError ("ScriptInterpreter::GetScriptCommands(StringList &) is not implemented.");
}
This is a very large commit that completely re-does the way lldb handles user settable internal variables (the equivalent of set/show variables in gdb). In addition to the basic infrastructure (most of which is defined in UserSettingsController.{h,cpp}, there are examples of two classes that have been set up to contain user settable variables (the Debugger and Process classes). The 'settings' command has been modified to be a command-subcommand structure, and the 'set', 'show' and 'append' commands have been moved into this sub-commabnd structure. The old StateVariable class has been completely replaced by this, and the state variable dictionary has been removed from the Command Interpreter. Places that formerly accessed the state variable mechanism have been modified to access the variables in this new structure instead (checking the term-width; getting/checking the prompt; etc.) Variables are attached to classes; there are two basic "flavors" of variables that can be set: "global" variables (static/class-wide), and "instance" variables (one per instance of the class). The whole thing has been set up so that any global or instance variable can be set at any time (e.g. on start up, in your .lldbinit file), whether or not any instances actually exist (there's a whole pending and default values mechanism to help deal with that). llvm-svn: 113041
2010-09-04 08:03:46 +08:00
std::string
ScriptInterpreter::LanguageToString (lldb::ScriptLanguage language)
{
std::string return_value;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
This is a very large commit that completely re-does the way lldb handles user settable internal variables (the equivalent of set/show variables in gdb). In addition to the basic infrastructure (most of which is defined in UserSettingsController.{h,cpp}, there are examples of two classes that have been set up to contain user settable variables (the Debugger and Process classes). The 'settings' command has been modified to be a command-subcommand structure, and the 'set', 'show' and 'append' commands have been moved into this sub-commabnd structure. The old StateVariable class has been completely replaced by this, and the state variable dictionary has been removed from the Command Interpreter. Places that formerly accessed the state variable mechanism have been modified to access the variables in this new structure instead (checking the term-width; getting/checking the prompt; etc.) Variables are attached to classes; there are two basic "flavors" of variables that can be set: "global" variables (static/class-wide), and "instance" variables (one per instance of the class). The whole thing has been set up so that any global or instance variable can be set at any time (e.g. on start up, in your .lldbinit file), whether or not any instances actually exist (there's a whole pending and default values mechanism to help deal with that). llvm-svn: 113041
2010-09-04 08:03:46 +08:00
switch (language)
{
case eScriptLanguageNone:
return_value = "None";
break;
case eScriptLanguagePython:
return_value = "Python";
break;
}
return return_value;
}
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 08:29:16 +08:00
Allow "breakpoint command add" to add commands to more than one breakpoint at a time. <rdar://problem/13314462> llvm-svn: 216747
2014-08-30 01:34:17 +08:00
Error
ScriptInterpreter::SetBreakpointCommandCallback (std::vector<BreakpointOptions *> &bp_options_vec,
const char *callback_text)
{
Error return_error;
for (BreakpointOptions *bp_options : bp_options_vec)
{
return_error = SetBreakpointCommandCallback(bp_options, callback_text);
if (return_error.Success())
break;
}
return return_error;
}
void
ScriptInterpreter::SetBreakpointCommandCallbackFunction (std::vector<BreakpointOptions *> &bp_options_vec,
const char *function_name)
{
for (BreakpointOptions *bp_options : bp_options_vec)
{
SetBreakpointCommandCallbackFunction(bp_options, function_name);
}
}
After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11. llvm-svn: 179805
2013-04-19 06:45:39 +08:00
std::unique_ptr<ScriptInterpreterLocker>
Implementing the notion of externally-acquirable ScriptInterpreter lock With this notion, if parties outside the ScriptInterpreter itself need to acquire a lock on script APIs, they can do so by a pattern like this: { auto lock = interpeter->AcquireInterpreterLock(); // do whatever you need to do... } // lock will automatically be released here This might be useful for classes that use the Python convenience objects (e.g. PythonDictionary) to ensure they keep the underlying interpreter in a safe and controlled condition while they call through the C API functions Of course, the ScriptInterpreter still manages its internal locking correctly when necessary :-) llvm-svn: 178189
2013-03-28 06:38:11 +08:00
ScriptInterpreter::AcquireInterpreterLock ()
{
After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11. llvm-svn: 179805
2013-04-19 06:45:39 +08:00
return std::unique_ptr<ScriptInterpreterLocker>(new ScriptInterpreterLocker());
Implementing the notion of externally-acquirable ScriptInterpreter lock With this notion, if parties outside the ScriptInterpreter itself need to acquire a lock on script APIs, they can do so by a pattern like this: { auto lock = interpeter->AcquireInterpreterLock(); // do whatever you need to do... } // lock will automatically be released here This might be useful for classes that use the Python convenience objects (e.g. PythonDictionary) to ensure they keep the underlying interpreter in a safe and controlled condition while they call through the C API functions Of course, the ScriptInterpreter still manages its internal locking correctly when necessary :-) llvm-svn: 178189
2013-03-28 06:38:11 +08: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 08:29:16 +08:00
void
Fixed the MacOSX non "Debug" builds so that "lldb-platform" doesn't fail to link. llvm-svn: 192857
2013-10-17 08:27:14 +08:00
ScriptInterpreter::InitializeInterpreter (SWIGInitCallback python_swig_init_callback,
SWIGBreakpointCallbackFunction swig_breakpoint_callback,
SWIGWatchpointCallbackFunction swig_watchpoint_callback,
SWIGPythonTypeScriptCallbackFunction swig_typescript_callback,
SWIGPythonCreateSyntheticProvider swig_synthetic_script,
SWIGPythonCalculateNumChildren swig_calc_children,
SWIGPythonGetChildAtIndex swig_get_child_index,
SWIGPythonGetIndexOfChildWithName swig_get_index_child,
SWIGPythonCastPyObjectToSBValue swig_cast_to_sbvalue ,
SWIGPythonGetValueObjectSPFromSBValue swig_get_valobj_sp_from_sbvalue,
SWIGPythonUpdateSynthProviderInstance swig_update_provider,
SWIGPythonMightHaveChildrenSynthProviderInstance swig_mighthavechildren_provider,
Extend synthetic children to produce synthetic values (as in, those that GetValueAsUnsigned(), GetValueAsCString() would return) The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function. If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value The rationale for doing things this way is twofold: - there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial - we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature Comes with a test case llvm-svn: 219330
2014-10-09 02:27:36 +08:00
SWIGPythonGetValueSynthProviderInstance swig_getvalue_provider,
Fixed the MacOSX non "Debug" builds so that "lldb-platform" doesn't fail to link. llvm-svn: 192857
2013-10-17 08:27:14 +08:00
SWIGPythonCallCommand swig_call_command,
SWIGPythonCallModuleInit swig_call_module_init,
SWIGPythonCreateOSPlugin swig_create_os_plugin,
SWIGPythonScriptKeyword_Process swig_run_script_keyword_process,
SWIGPythonScriptKeyword_Thread swig_run_script_keyword_thread,
SWIGPythonScriptKeyword_Target swig_run_script_keyword_target,
SWIGPythonScriptKeyword_Frame swig_run_script_keyword_frame,
Add a feature where a string data formatter can now be partially composed of Python summary functions This works similarly to the {thread/frame/process/target.script:...} feature - you write a summary string, part of which is ${var.script:someFuncName} someFuncName is expected to be declared as def someFuncName(SBValue,otherArgument) - essentially the same as a summary function Since . -> [] are the only allowed separators, and % is used for custom formatting, .script: would not be a legitimate symbol anyway, which makes this non-ambiguous llvm-svn: 220821
2014-10-29 05:07:00 +08:00
SWIGPythonScriptKeyword_Value swig_run_script_keyword_value,
This checkin is the first step in making the lldb thread stepping mechanism more accessible from the user level. It adds the ability to invent new stepping modes implemented by python classes, and to view the current thread plan stack and to some extent alter it. I haven't gotten to documentation or tests yet. But this should not cause any behavior changes if you don't use it, so its safe to check it in now and work on it incrementally. llvm-svn: 218642
2014-09-30 07:17:18 +08:00
SWIGPython_GetDynamicSetting swig_plugin_get,
SWIGPythonCreateScriptedThreadPlan swig_thread_plan_script,
SWIGPythonCallThreadPlan swig_call_thread_plan)
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 08:29:16 +08:00
{
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 11:34:56 +08:00
#ifndef LLDB_DISABLE_PYTHON
Fixed the MacOSX non "Debug" builds so that "lldb-platform" doesn't fail to link. llvm-svn: 192857
2013-10-17 08:27:14 +08:00
ScriptInterpreterPython::InitializeInterpreter (python_swig_init_callback,
swig_breakpoint_callback,
swig_watchpoint_callback,
swig_typescript_callback,
swig_synthetic_script,
swig_calc_children,
swig_get_child_index,
swig_get_index_child,
swig_cast_to_sbvalue ,
swig_get_valobj_sp_from_sbvalue,
swig_update_provider,
swig_mighthavechildren_provider,
Extend synthetic children to produce synthetic values (as in, those that GetValueAsUnsigned(), GetValueAsCString() would return) The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function. If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value The rationale for doing things this way is twofold: - there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial - we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature Comes with a test case llvm-svn: 219330
2014-10-09 02:27:36 +08:00
swig_getvalue_provider,
Fixed the MacOSX non "Debug" builds so that "lldb-platform" doesn't fail to link. llvm-svn: 192857
2013-10-17 08:27:14 +08:00
swig_call_command,
swig_call_module_init,
swig_create_os_plugin,
swig_run_script_keyword_process,
swig_run_script_keyword_thread,
swig_run_script_keyword_target,
swig_run_script_keyword_frame,
Add a feature where a string data formatter can now be partially composed of Python summary functions This works similarly to the {thread/frame/process/target.script:...} feature - you write a summary string, part of which is ${var.script:someFuncName} someFuncName is expected to be declared as def someFuncName(SBValue,otherArgument) - essentially the same as a summary function Since . -> [] are the only allowed separators, and % is used for custom formatting, .script: would not be a legitimate symbol anyway, which makes this non-ambiguous llvm-svn: 220821
2014-10-29 05:07:00 +08:00
swig_run_script_keyword_value,
This checkin is the first step in making the lldb thread stepping mechanism more accessible from the user level. It adds the ability to invent new stepping modes implemented by python classes, and to view the current thread plan stack and to some extent alter it. I haven't gotten to documentation or tests yet. But this should not cause any behavior changes if you don't use it, so its safe to check it in now and work on it incrementally. llvm-svn: 218642
2014-09-30 07:17:18 +08:00
swig_plugin_get,
swig_thread_plan_script,
swig_call_thread_plan);
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 11:34:56 +08:00
#endif // #ifndef LLDB_DISABLE_PYTHON
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 08:29:16 +08:00
}