This patch can only be successfully applied to a repo that already has [1/2] applied. This is the core meat of the change.
See D7946 for more context and information about this patch.
Details
Details
Diff Detail
Diff Detail
Event Timeline
Comment Actions
Bah. It looks like I need to fix the formatting. I didn't notice it when it was all one gigantic changelist, but now that it's not, I noticed that "git clang-format" reformatted the entire patch. Hold off on this until I get that straightened out.
Comment Actions
I almost fixed the argdumper linker errors, but there's a problem.
OperatingSystemPython is linked into lldb-core, so when argdumper links against lldb-core.a, it tries to link OperatingSystemPython, which then requires we bring in everything else. But we can't link API into lldb-core, so it doesn't work.
Is it possible to have OperatingSystemPython not be part of lldb-core, but instead be part of lldb-core-python or something? This way argdumper could just link against lldb-core.a but not lldb-core-python.a, and lldb could link against both.
I don't know how to set this up in Xcode though.
Comment Actions
Rebase against ToT. See part 1 for more information. This patch and part 1 are coupled, please make sure to apply them at the same time.
Comment Actions
So seems like part of the work required for this patch to work is to change any references in code from PythonList, PythonString, PythonInteger, and PythonDictionary to use classes from lldb/Core/StructuredData.h.
The means we probably need to have OperatingSystemPython rely only upon virtual functions in ScriptInterpreter and have those functions return stuff from StructuredData instead of python variants:
PythonDictionary dictionary(m_interpreter->OSPlugin_RegisterInfo(m_python_object_sp));
Will need to become:
StructuredData::Dictionary dictionary(m_interpreter->OSPlugin_RegisterInfo(m_python_object_sp));
We then need to modify the Python callbacks that return PythonList, PythonString, PythonInteger, and PythonDictionary objects, to convert them into StructuredData::Array, StructuredData::String, StructuredData::Integer and StructuredData::Dictionary respectively.
Comment Actions
ProcessGDBRemote::ParsePythonTargetDefinition() will also need to be updated to use StructuredData objects and the conversion from Python to StructuredData objects will need to be done in ScriptInterpreterPython.
So:
lldb::ScriptInterpreterObjectSP target_definition_sp (interpreter->GetDynamicSettings(module_object_sp,
&GetTarget(),
"gdb-server-target-definition",
error));
PythonDictionary target_dict(target_definition_sp);Will need to become:
lldb::StructuredDataObjectSP target_definition_sp (interpreter->GetDynamicSettings(module_object_sp,
&GetTarget(),
"gdb-server-target-definition",
error));
StructuredData::Dictionary *dict = target_definition_sp->GetAsDictionary();
if (dict)
{
}So Python* data types should _only_ exist in ScriptInterpreterPython code and should always be converted to StructuredData types before being given out to any code within LLDB.
Comment Actions
There is one more issue which I was unable to solve, which is that
ScriptInterpreter::Initialize() calls
ScriptInterpreterPython::Initialize(). So anyone linking against
liblldb-core.a needs to pull in the python stuff too, which isn't always
possible. This works fine in the CMake build, but I wasn't able to figure
out how to make it work in the Xcode build. I could get argdumper to
build, but not lldb-server. If I tried to have lldb-server depend on the
python stuff under API\Bindings\Python, then I got errors about not being
able to find SB classes, I guess because of something to do with framework?
Comment Actions
SBCommandInterpreter::InitializeSWIG () seems like a good place to do this. This could be renamed to be InitializeScriptInterpreters() and then you can do this if and only if python is enabled.
Comment Actions
SBDebugger::Initialize () is the main function that must be called prior to using anything in the lldb::SB* layer, and it currently looks like:
void
SBDebugger::Initialize ()
{
Log *log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
if (log)
log->Printf ("SBDebugger::Initialize ()");
SBCommandInterpreter::InitializeSWIG ();
Debugger::Initialize(LoadPlugin);
}You might need to call Debugger::Initialize() first so all plug-ins registers themselves, and then call SBCommandInterpreter::InitializeScriptInterpreters() after to ensure everything is setup as the ScriptInterpreterPython will need to register itself with the ScriptInterpreter if it already isn't doing so.
Comment Actions
ScriptInterpreter will need to keep a map of language to static create functions (ScriptInterpreterPython::CreateInstance()) so it can create the interpreter when needed. So the SBCommandInterpreter::InitializeScriptInterpreter() would:
1 - initialize all supported languages (ScriptInterpreterPython::Initialize())
2 - call ScriptInterpreter::Initialize() which would finalize the current script interpreters and select a default one for execution by checking the setting:
(lldb) settings show script-lang
script-lang (enum) = python
The default language is gettable using Debugger::GetScriptLanguage().
Comment Actions
I think this part needs to be done as a separate patch. Makes it easier to
review and understand the impact of. So I will do this part first
(basically delete ScriptInterpreterObject and move everything to
StructuredData) and commit that, then rebase this on top of that and go
from there.