[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 15:23:27 +08:00
|
|
|
//===-- OperatingSystemPython.cpp -----------------------------------------===//
|
2012-08-24 05:17:11 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2012-08-24 05:17:11 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
2012-12-05 08:20:57 +08:00
|
|
|
|
2019-12-11 00:54:30 +08:00
|
|
|
#include "lldb/Host/Config.h"
|
|
|
|
|
2019-12-14 02:37:33 +08:00
|
|
|
#if LLDB_ENABLE_PYTHON
|
2012-08-24 05:17:11 +08:00
|
|
|
|
|
|
|
#include "OperatingSystemPython.h"
|
2019-02-12 07:13:08 +08:00
|
|
|
|
2012-08-24 05:17:11 +08:00
|
|
|
#include "Plugins/Process/Utility/DynamicRegisterInfo.h"
|
2013-04-23 02:26:52 +08:00
|
|
|
#include "Plugins/Process/Utility/RegisterContextDummy.h"
|
2012-08-24 05:17:11 +08:00
|
|
|
#include "Plugins/Process/Utility/RegisterContextMemory.h"
|
|
|
|
#include "Plugins/Process/Utility/ThreadMemory.h"
|
2012-08-24 08:30:47 +08:00
|
|
|
#include "lldb/Core/Debugger.h"
|
2012-08-24 05:17:11 +08:00
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
#include "lldb/Core/PluginManager.h"
|
|
|
|
#include "lldb/Core/ValueObjectVariable.h"
|
2012-08-24 08:30:47 +08:00
|
|
|
#include "lldb/Interpreter/CommandInterpreter.h"
|
2015-03-18 04:04:04 +08:00
|
|
|
#include "lldb/Interpreter/ScriptInterpreter.h"
|
2012-08-24 05:17:11 +08:00
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
|
|
|
#include "lldb/Symbol/VariableList.h"
|
|
|
|
#include "lldb/Target/Process.h"
|
|
|
|
#include "lldb/Target/StopInfo.h"
|
|
|
|
#include "lldb/Target/Target.h"
|
|
|
|
#include "lldb/Target/Thread.h"
|
|
|
|
#include "lldb/Target/ThreadList.h"
|
2017-03-04 09:30:05 +08:00
|
|
|
#include "lldb/Utility/DataBufferHeap.h"
|
2018-08-07 19:07:21 +08:00
|
|
|
#include "lldb/Utility/RegisterValue.h"
|
2017-02-03 05:39:50 +08:00
|
|
|
#include "lldb/Utility/StreamString.h"
|
2017-06-27 18:45:31 +08:00
|
|
|
#include "lldb/Utility/StructuredData.h"
|
2012-08-24 05:17:11 +08:00
|
|
|
|
2019-02-12 07:13:08 +08:00
|
|
|
#include <memory>
|
|
|
|
|
2012-08-24 05:17:11 +08:00
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
|
|
void OperatingSystemPython::Initialize() {
|
2015-09-17 05:20:44 +08:00
|
|
|
PluginManager::RegisterPlugin(GetPluginNameStatic(),
|
|
|
|
GetPluginDescriptionStatic(), CreateInstance,
|
|
|
|
nullptr);
|
2012-08-24 05:17:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void OperatingSystemPython::Terminate() {
|
|
|
|
PluginManager::UnregisterPlugin(CreateInstance);
|
|
|
|
}
|
|
|
|
|
|
|
|
OperatingSystem *OperatingSystemPython::CreateInstance(Process *process,
|
|
|
|
bool force) {
|
2018-05-01 00:49:04 +08:00
|
|
|
// Python OperatingSystem plug-ins must be requested by name, so force must
|
|
|
|
// be true
|
2012-10-19 06:40:37 +08:00
|
|
|
FileSpec python_os_plugin_spec(process->GetPythonOSPluginPath());
|
2018-11-02 01:09:25 +08:00
|
|
|
if (python_os_plugin_spec &&
|
|
|
|
FileSystem::Instance().Exists(python_os_plugin_spec)) {
|
2019-02-13 14:25:41 +08:00
|
|
|
std::unique_ptr<OperatingSystemPython> os_up(
|
2013-04-19 06:45:39 +08:00
|
|
|
new OperatingSystemPython(process, python_os_plugin_spec));
|
2019-02-13 14:25:41 +08:00
|
|
|
if (os_up.get() && os_up->IsValid())
|
|
|
|
return os_up.release();
|
2012-10-19 06:40:37 +08:00
|
|
|
}
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
return nullptr;
|
2012-08-24 05:17:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ConstString OperatingSystemPython::GetPluginNameStatic() {
|
2013-05-11 05:47:16 +08:00
|
|
|
static ConstString g_name("python");
|
|
|
|
return g_name;
|
2012-08-24 05:17:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
const char *OperatingSystemPython::GetPluginDescriptionStatic() {
|
|
|
|
return "Operating system plug-in that gathers OS information from a python "
|
|
|
|
"class that implements the necessary OperatingSystem functionality.";
|
|
|
|
}
|
|
|
|
|
2012-10-19 06:40:37 +08:00
|
|
|
OperatingSystemPython::OperatingSystemPython(lldb_private::Process *process,
|
|
|
|
const FileSpec &python_module_path)
|
2019-02-13 14:25:41 +08:00
|
|
|
: OperatingSystem(process), m_thread_list_valobj_sp(), m_register_info_up(),
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
m_interpreter(nullptr), m_python_object_sp() {
|
2012-08-24 08:30:47 +08:00
|
|
|
if (!process)
|
|
|
|
return;
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
TargetSP target_sp = process->CalculateTarget();
|
2012-08-24 08:30:47 +08:00
|
|
|
if (!target_sp)
|
|
|
|
return;
|
2019-04-27 06:43:16 +08:00
|
|
|
m_interpreter = target_sp->GetDebugger().GetScriptInterpreter();
|
2012-08-24 08:30:47 +08:00
|
|
|
if (m_interpreter) {
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-10-19 06:40:37 +08:00
|
|
|
std::string os_plugin_class_name(
|
|
|
|
python_module_path.GetFilename().AsCString(""));
|
|
|
|
if (!os_plugin_class_name.empty()) {
|
|
|
|
const bool init_session = false;
|
|
|
|
char python_module_path_cstr[PATH_MAX];
|
|
|
|
python_module_path.GetPath(python_module_path_cstr,
|
|
|
|
sizeof(python_module_path_cstr));
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error;
|
2019-12-23 13:35:05 +08:00
|
|
|
if (m_interpreter->LoadScriptingModule(python_module_path_cstr,
|
|
|
|
init_session, error)) {
|
2012-10-19 06:40:37 +08:00
|
|
|
// Strip the ".py" extension if there is one
|
|
|
|
size_t py_extension_pos = os_plugin_class_name.rfind(".py");
|
|
|
|
if (py_extension_pos != std::string::npos)
|
|
|
|
os_plugin_class_name.erase(py_extension_pos);
|
|
|
|
// Add ".OperatingSystemPlugIn" to the module name to get a string like
|
|
|
|
// "modulename.OperatingSystemPlugIn"
|
|
|
|
os_plugin_class_name += ".OperatingSystemPlugIn";
|
2015-03-18 04:04:04 +08:00
|
|
|
StructuredData::ObjectSP object_sp =
|
|
|
|
m_interpreter->OSPlugin_CreatePluginObject(
|
|
|
|
os_plugin_class_name.c_str(), process->CalculateProcess());
|
|
|
|
if (object_sp && object_sp->IsValid())
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
m_python_object_sp = object_sp;
|
2012-08-24 09:42:50 +08:00
|
|
|
}
|
2012-08-24 08:30:47 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2012-08-24 05:17:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
OperatingSystemPython::~OperatingSystemPython() {}
|
|
|
|
|
|
|
|
DynamicRegisterInfo *OperatingSystemPython::GetDynamicRegisterInfo() {
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
if (m_register_info_up == nullptr) {
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
if (!m_interpreter || !m_python_object_sp)
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
return nullptr;
|
2013-05-23 07:04:27 +08:00
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_OS));
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
"OperatingSystemPython::GetDynamicRegisterInfo() fetching "
|
|
|
|
"thread register definitions from python for pid %" PRIu64,
|
|
|
|
m_process->GetID());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-03-18 04:04:04 +08:00
|
|
|
StructuredData::DictionarySP dictionary =
|
|
|
|
m_interpreter->OSPlugin_RegisterInfo(m_python_object_sp);
|
2012-08-24 09:42:50 +08:00
|
|
|
if (!dictionary)
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-02-13 14:25:41 +08:00
|
|
|
m_register_info_up.reset(new DynamicRegisterInfo(
|
2015-05-27 02:00:51 +08:00
|
|
|
*dictionary, m_process->GetTarget().GetArchitecture()));
|
2019-02-13 14:25:41 +08:00
|
|
|
assert(m_register_info_up->GetNumRegisters() > 0);
|
|
|
|
assert(m_register_info_up->GetNumRegisterSets() > 0);
|
2012-08-24 05:17:11 +08:00
|
|
|
}
|
2019-02-13 14:25:41 +08:00
|
|
|
return m_register_info_up.get();
|
2012-08-24 05:17:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// PluginInterface protocol
|
|
|
|
ConstString OperatingSystemPython::GetPluginName() {
|
|
|
|
return GetPluginNameStatic();
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t OperatingSystemPython::GetPluginVersion() { return 1; }
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2013-05-08 02:35:34 +08:00
|
|
|
bool OperatingSystemPython::UpdateThreadList(ThreadList &old_thread_list,
|
|
|
|
ThreadList &core_thread_list,
|
|
|
|
ThreadList &new_thread_list) {
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
if (!m_interpreter || !m_python_object_sp)
|
2012-12-08 06:21:08 +08:00
|
|
|
return false;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2013-05-23 07:04:27 +08:00
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_OS));
|
2016-09-07 04:57:50 +08:00
|
|
|
|
Prevent deadlock in OS Plugins
Summary:
When performing a synchronous resume, the API mutex is held until the
process is stopped. This is fine, except for when the OS plugins are processing
an event before the main thread is aware of it, in which case we end up with a
deadlock because in the internal thread we acquire a resource lock first, and
then wait for the API lock, while in the main thread we do the opposite, we
already hold the API mutex but are now waiting for the event mutex to handle
the event.
This patch fixes this by relaxing the need for the API lock in the OS plugins.
We can get away with this because we now this code is executed in the main
thread. As stated in the comment above, we just want to ensure nobody else
messes with the API while we're making a change. In theory it's possible that
the main thread would release the lock while we're executing the function, but
prevent this would require a more structural solution (which we want, but do
not have today).
The same workaround was already present, but this patch generalizes it to the
whole file.
This will allow me to re-land r329891.
Reviewers: clayborg, jingham, labath
Subscribers: llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D45586
llvm-svn: 330002
2018-04-13 18:25:23 +08:00
|
|
|
// First thing we have to do is to try to get the API lock, and the
|
|
|
|
// interpreter lock. We're going to change the thread content of the process,
|
|
|
|
// and we're going to use python, which requires the API lock to do it. We
|
|
|
|
// need the interpreter lock to make sure thread_info_dict stays alive.
|
2015-04-08 06:17:41 +08:00
|
|
|
//
|
|
|
|
// If someone already has the API lock, that is ok, we just want to avoid
|
|
|
|
// external code from making new API calls while this call is happening.
|
|
|
|
//
|
|
|
|
// This is a recursive lock so we can grant it to any Python code called on
|
|
|
|
// the stack below us.
|
2012-12-08 01:42:15 +08:00
|
|
|
Target &target = m_process->GetTarget();
|
Prevent deadlock in OS Plugins
Summary:
When performing a synchronous resume, the API mutex is held until the
process is stopped. This is fine, except for when the OS plugins are processing
an event before the main thread is aware of it, in which case we end up with a
deadlock because in the internal thread we acquire a resource lock first, and
then wait for the API lock, while in the main thread we do the opposite, we
already hold the API mutex but are now waiting for the event mutex to handle
the event.
This patch fixes this by relaxing the need for the API lock in the OS plugins.
We can get away with this because we now this code is executed in the main
thread. As stated in the comment above, we just want to ensure nobody else
messes with the API while we're making a change. In theory it's possible that
the main thread would release the lock while we're executing the function, but
prevent this would require a more structural solution (which we want, but do
not have today).
The same workaround was already present, but this patch generalizes it to the
whole file.
This will allow me to re-land r329891.
Reviewers: clayborg, jingham, labath
Subscribers: llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D45586
llvm-svn: 330002
2018-04-13 18:25:23 +08:00
|
|
|
std::unique_lock<std::recursive_mutex> api_lock(target.GetAPIMutex(),
|
|
|
|
std::defer_lock);
|
2019-11-15 07:27:49 +08:00
|
|
|
(void)api_lock.try_lock(); // See above.
|
Prevent deadlock in OS Plugins
Summary:
When performing a synchronous resume, the API mutex is held until the
process is stopped. This is fine, except for when the OS plugins are processing
an event before the main thread is aware of it, in which case we end up with a
deadlock because in the internal thread we acquire a resource lock first, and
then wait for the API lock, while in the main thread we do the opposite, we
already hold the API mutex but are now waiting for the event mutex to handle
the event.
This patch fixes this by relaxing the need for the API lock in the OS plugins.
We can get away with this because we now this code is executed in the main
thread. As stated in the comment above, we just want to ensure nobody else
messes with the API while we're making a change. In theory it's possible that
the main thread would release the lock while we're executing the function, but
prevent this would require a more structural solution (which we want, but do
not have today).
The same workaround was already present, but this patch generalizes it to the
whole file.
This will allow me to re-land r329891.
Reviewers: clayborg, jingham, labath
Subscribers: llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D45586
llvm-svn: 330002
2018-04-13 18:25:23 +08:00
|
|
|
auto interpreter_lock = m_interpreter->AcquireInterpreterLock();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
"OperatingSystemPython::UpdateThreadList() fetching thread "
|
|
|
|
"data from python for pid %" PRIu64,
|
|
|
|
m_process->GetID());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-08-09 04:47:40 +08:00
|
|
|
// The threads that are in "core_thread_list" upon entry are the threads from
|
Prevent deadlock in OS Plugins
Summary:
When performing a synchronous resume, the API mutex is held until the
process is stopped. This is fine, except for when the OS plugins are processing
an event before the main thread is aware of it, in which case we end up with a
deadlock because in the internal thread we acquire a resource lock first, and
then wait for the API lock, while in the main thread we do the opposite, we
already hold the API mutex but are now waiting for the event mutex to handle
the event.
This patch fixes this by relaxing the need for the API lock in the OS plugins.
We can get away with this because we now this code is executed in the main
thread. As stated in the comment above, we just want to ensure nobody else
messes with the API while we're making a change. In theory it's possible that
the main thread would release the lock while we're executing the function, but
prevent this would require a more structural solution (which we want, but do
not have today).
The same workaround was already present, but this patch generalizes it to the
whole file.
This will allow me to re-land r329891.
Reviewers: clayborg, jingham, labath
Subscribers: llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D45586
llvm-svn: 330002
2018-04-13 18:25:23 +08:00
|
|
|
// the lldb_private::Process subclass, no memory threads will be in this
|
|
|
|
// list.
|
2015-03-18 04:04:04 +08:00
|
|
|
StructuredData::ArraySP threads_list =
|
2013-05-23 07:04:27 +08:00
|
|
|
m_interpreter->OSPlugin_ThreadsInfo(m_python_object_sp);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-03-18 04:04:04 +08:00
|
|
|
const uint32_t num_cores = core_thread_list.GetSize(false);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-03-18 04:04:04 +08:00
|
|
|
// Make a map so we can keep track of which cores were used from the
|
2018-05-01 00:49:04 +08:00
|
|
|
// core_thread list. Any real threads/cores that weren't used should later be
|
|
|
|
// put back into the "new_thread_list".
|
2015-03-18 04:04:04 +08:00
|
|
|
std::vector<bool> core_used_map(num_cores, false);
|
|
|
|
if (threads_list) {
|
2016-09-07 04:57:50 +08:00
|
|
|
if (log) {
|
2015-03-18 04:04:04 +08:00
|
|
|
StreamString strm;
|
|
|
|
threads_list->Dump(strm);
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log, "threads_list = %s", strm.GetData());
|
2012-08-24 13:45:15 +08:00
|
|
|
}
|
2014-02-14 07:34:38 +08:00
|
|
|
|
|
|
|
const uint32_t num_threads = threads_list->GetSize();
|
|
|
|
for (uint32_t i = 0; i < num_threads; ++i) {
|
|
|
|
StructuredData::ObjectSP thread_dict_obj =
|
|
|
|
threads_list->GetItemAtIndex(i);
|
|
|
|
if (auto thread_dict = thread_dict_obj->GetAsDictionary()) {
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
ThreadSP thread_sp(CreateThreadFromThreadInfo(
|
|
|
|
*thread_dict, core_thread_list, old_thread_list, core_used_map,
|
|
|
|
nullptr));
|
2015-03-18 04:04:04 +08:00
|
|
|
if (thread_sp)
|
2014-02-14 07:34:38 +08:00
|
|
|
new_thread_list.AddThread(thread_sp);
|
|
|
|
}
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2014-02-14 07:34:38 +08:00
|
|
|
// Any real core threads that didn't end up backing a memory thread should
|
|
|
|
// still be in the main thread list, and they should be inserted at the
|
2018-05-01 00:49:04 +08:00
|
|
|
// beginning of the list
|
2014-02-14 07:34:38 +08:00
|
|
|
uint32_t insert_idx = 0;
|
|
|
|
for (uint32_t core_idx = 0; core_idx < num_cores; ++core_idx) {
|
2018-12-15 08:15:33 +08:00
|
|
|
if (!core_used_map[core_idx]) {
|
2015-03-18 04:04:04 +08:00
|
|
|
new_thread_list.InsertThread(
|
|
|
|
core_thread_list.GetThreadAtIndex(core_idx, false), insert_idx);
|
2014-02-14 07:34:38 +08:00
|
|
|
++insert_idx;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
}
|
2013-05-09 09:55:29 +08:00
|
|
|
|
2012-08-24 05:17:11 +08:00
|
|
|
return new_thread_list.GetSize(false) > 0;
|
|
|
|
}
|
|
|
|
|
2015-03-18 04:04:04 +08:00
|
|
|
ThreadSP OperatingSystemPython::CreateThreadFromThreadInfo(
|
|
|
|
StructuredData::Dictionary &thread_dict, ThreadList &core_thread_list,
|
|
|
|
ThreadList &old_thread_list, std::vector<bool> &core_used_map,
|
|
|
|
bool *did_create_ptr) {
|
|
|
|
ThreadSP thread_sp;
|
|
|
|
tid_t tid = LLDB_INVALID_THREAD_ID;
|
|
|
|
if (!thread_dict.GetValueForKeyAsInteger("tid", tid))
|
|
|
|
return ThreadSP();
|
|
|
|
|
|
|
|
uint32_t core_number;
|
|
|
|
addr_t reg_data_addr;
|
2017-05-12 13:49:54 +08:00
|
|
|
llvm::StringRef name;
|
|
|
|
llvm::StringRef queue;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-03-18 04:04:04 +08:00
|
|
|
thread_dict.GetValueForKeyAsInteger("core", core_number, UINT32_MAX);
|
|
|
|
thread_dict.GetValueForKeyAsInteger("register_data_addr", reg_data_addr,
|
|
|
|
LLDB_INVALID_ADDRESS);
|
|
|
|
thread_dict.GetValueForKeyAsString("name", name);
|
|
|
|
thread_dict.GetValueForKeyAsString("queue", queue);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-03-18 04:04:04 +08:00
|
|
|
// See if a thread already exists for "tid"
|
|
|
|
thread_sp = old_thread_list.FindThreadByID(tid, false);
|
|
|
|
if (thread_sp) {
|
|
|
|
// A thread already does exist for "tid", make sure it was an operating
|
|
|
|
// system
|
|
|
|
// plug-in generated thread.
|
|
|
|
if (!IsOperatingSystemPluginThread(thread_sp)) {
|
|
|
|
// We have thread ID overlap between the protocol threads and the
|
2018-05-01 00:49:04 +08:00
|
|
|
// operating system threads, clear the thread so we create an operating
|
|
|
|
// system thread for this.
|
2015-03-18 04:04:04 +08:00
|
|
|
thread_sp.reset();
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2015-03-18 04:04:04 +08:00
|
|
|
if (!thread_sp) {
|
|
|
|
if (did_create_ptr)
|
|
|
|
*did_create_ptr = true;
|
2019-02-12 07:13:08 +08:00
|
|
|
thread_sp = std::make_shared<ThreadMemory>(*m_process, tid, name, queue,
|
|
|
|
reg_data_addr);
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2015-03-18 04:04:04 +08:00
|
|
|
if (core_number < core_thread_list.GetSize(false)) {
|
|
|
|
ThreadSP core_thread_sp(
|
|
|
|
core_thread_list.GetThreadAtIndex(core_number, false));
|
|
|
|
if (core_thread_sp) {
|
|
|
|
// Keep track of which cores were set as the backing thread for memory
|
|
|
|
// threads...
|
|
|
|
if (core_number < core_used_map.size())
|
|
|
|
core_used_map[core_number] = true;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-03-18 04:04:04 +08:00
|
|
|
ThreadSP backing_core_thread_sp(core_thread_sp->GetBackingThread());
|
|
|
|
if (backing_core_thread_sp) {
|
|
|
|
thread_sp->SetBackingThread(backing_core_thread_sp);
|
|
|
|
} else {
|
|
|
|
thread_sp->SetBackingThread(core_thread_sp);
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
}
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
return thread_sp;
|
|
|
|
}
|
|
|
|
|
2012-08-24 05:17:11 +08:00
|
|
|
void OperatingSystemPython::ThreadWasSelected(Thread *thread) {}
|
|
|
|
|
|
|
|
RegisterContextSP
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
OperatingSystemPython::CreateRegisterContextForThread(Thread *thread,
|
|
|
|
addr_t reg_data_addr) {
|
2012-08-24 13:45:15 +08:00
|
|
|
RegisterContextSP reg_ctx_sp;
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
if (!m_interpreter || !m_python_object_sp || !thread)
|
2013-05-02 05:54:04 +08:00
|
|
|
return reg_ctx_sp;
|
2012-12-08 01:42:15 +08:00
|
|
|
|
2013-03-28 07:08:40 +08:00
|
|
|
if (!IsOperatingSystemPluginThread(thread->shared_from_this()))
|
2013-05-02 05:54:04 +08:00
|
|
|
return reg_ctx_sp;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
Prevent deadlock in OS Plugins
Summary:
When performing a synchronous resume, the API mutex is held until the
process is stopped. This is fine, except for when the OS plugins are processing
an event before the main thread is aware of it, in which case we end up with a
deadlock because in the internal thread we acquire a resource lock first, and
then wait for the API lock, while in the main thread we do the opposite, we
already hold the API mutex but are now waiting for the event mutex to handle
the event.
This patch fixes this by relaxing the need for the API lock in the OS plugins.
We can get away with this because we now this code is executed in the main
thread. As stated in the comment above, we just want to ensure nobody else
messes with the API while we're making a change. In theory it's possible that
the main thread would release the lock while we're executing the function, but
prevent this would require a more structural solution (which we want, but do
not have today).
The same workaround was already present, but this patch generalizes it to the
whole file.
This will allow me to re-land r329891.
Reviewers: clayborg, jingham, labath
Subscribers: llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D45586
llvm-svn: 330002
2018-04-13 18:25:23 +08:00
|
|
|
// First thing we have to do is to try to get the API lock, and the
|
|
|
|
// interpreter lock. We're going to change the thread content of the process,
|
|
|
|
// and we're going to use python, which requires the API lock to do it. We
|
|
|
|
// need the interpreter lock to make sure thread_info_dict stays alive.
|
|
|
|
//
|
|
|
|
// If someone already has the API lock, that is ok, we just want to avoid
|
|
|
|
// external code from making new API calls while this call is happening.
|
|
|
|
//
|
|
|
|
// This is a recursive lock so we can grant it to any Python code called on
|
|
|
|
// the stack below us.
|
2012-12-08 01:42:15 +08:00
|
|
|
Target &target = m_process->GetTarget();
|
Prevent deadlock in OS Plugins
Summary:
When performing a synchronous resume, the API mutex is held until the
process is stopped. This is fine, except for when the OS plugins are processing
an event before the main thread is aware of it, in which case we end up with a
deadlock because in the internal thread we acquire a resource lock first, and
then wait for the API lock, while in the main thread we do the opposite, we
already hold the API mutex but are now waiting for the event mutex to handle
the event.
This patch fixes this by relaxing the need for the API lock in the OS plugins.
We can get away with this because we now this code is executed in the main
thread. As stated in the comment above, we just want to ensure nobody else
messes with the API while we're making a change. In theory it's possible that
the main thread would release the lock while we're executing the function, but
prevent this would require a more structural solution (which we want, but do
not have today).
The same workaround was already present, but this patch generalizes it to the
whole file.
This will allow me to re-land r329891.
Reviewers: clayborg, jingham, labath
Subscribers: llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D45586
llvm-svn: 330002
2018-04-13 18:25:23 +08:00
|
|
|
std::unique_lock<std::recursive_mutex> api_lock(target.GetAPIMutex(),
|
|
|
|
std::defer_lock);
|
2019-11-15 07:27:49 +08:00
|
|
|
(void)api_lock.try_lock(); // See above.
|
Prevent deadlock in OS Plugins
Summary:
When performing a synchronous resume, the API mutex is held until the
process is stopped. This is fine, except for when the OS plugins are processing
an event before the main thread is aware of it, in which case we end up with a
deadlock because in the internal thread we acquire a resource lock first, and
then wait for the API lock, while in the main thread we do the opposite, we
already hold the API mutex but are now waiting for the event mutex to handle
the event.
This patch fixes this by relaxing the need for the API lock in the OS plugins.
We can get away with this because we now this code is executed in the main
thread. As stated in the comment above, we just want to ensure nobody else
messes with the API while we're making a change. In theory it's possible that
the main thread would release the lock while we're executing the function, but
prevent this would require a more structural solution (which we want, but do
not have today).
The same workaround was already present, but this patch generalizes it to the
whole file.
This will allow me to re-land r329891.
Reviewers: clayborg, jingham, labath
Subscribers: llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D45586
llvm-svn: 330002
2018-04-13 18:25:23 +08:00
|
|
|
auto interpreter_lock = m_interpreter->AcquireInterpreterLock();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2013-03-28 07:08:40 +08:00
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_THREAD));
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-10-26 01:56:31 +08:00
|
|
|
if (reg_data_addr != LLDB_INVALID_ADDRESS) {
|
|
|
|
// The registers data is in contiguous memory, just create the register
|
|
|
|
// context using the address provided
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
"OperatingSystemPython::CreateRegisterContextForThread (tid "
|
|
|
|
"= 0x%" PRIx64 ", 0x%" PRIx64 ", reg_data_addr = 0x%" PRIx64
|
|
|
|
") creating memory register context",
|
|
|
|
thread->GetID(), thread->GetProtocolID(), reg_data_addr);
|
2019-02-12 07:13:08 +08:00
|
|
|
reg_ctx_sp = std::make_shared<RegisterContextMemory>(
|
|
|
|
*thread, 0, *GetDynamicRegisterInfo(), reg_data_addr);
|
2012-10-26 01:56:31 +08:00
|
|
|
} else {
|
2018-05-01 00:49:04 +08:00
|
|
|
// No register data address is provided, query the python plug-in to let it
|
|
|
|
// make up the data as it sees fit
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
"OperatingSystemPython::CreateRegisterContextForThread (tid "
|
|
|
|
"= 0x%" PRIx64 ", 0x%" PRIx64
|
|
|
|
") fetching register data from python",
|
|
|
|
thread->GetID(), thread->GetProtocolID());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-03-18 04:04:04 +08:00
|
|
|
StructuredData::StringSP reg_context_data =
|
|
|
|
m_interpreter->OSPlugin_RegisterContextData(m_python_object_sp,
|
|
|
|
thread->GetID());
|
2012-10-26 01:56:31 +08:00
|
|
|
if (reg_context_data) {
|
2020-01-29 03:23:46 +08:00
|
|
|
std::string value = std::string(reg_context_data->GetValue());
|
2015-03-18 04:04:04 +08:00
|
|
|
DataBufferSP data_sp(new DataBufferHeap(value.c_str(), value.length()));
|
2012-10-26 01:56:31 +08:00
|
|
|
if (data_sp->GetByteSize()) {
|
|
|
|
RegisterContextMemory *reg_ctx_memory = new RegisterContextMemory(
|
|
|
|
*thread, 0, *GetDynamicRegisterInfo(), LLDB_INVALID_ADDRESS);
|
|
|
|
if (reg_ctx_memory) {
|
|
|
|
reg_ctx_sp.reset(reg_ctx_memory);
|
|
|
|
reg_ctx_memory->SetAllRegisterData(data_sp);
|
2012-08-24 13:45:15 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2012-08-24 13:45:15 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2013-04-23 02:26:52 +08:00
|
|
|
// if we still have no register data, fallback on a dummy context to avoid
|
|
|
|
// crashing
|
|
|
|
if (!reg_ctx_sp) {
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
"OperatingSystemPython::CreateRegisterContextForThread (tid "
|
|
|
|
"= 0x%" PRIx64 ") forcing a dummy register context",
|
|
|
|
thread->GetID());
|
2019-02-12 07:13:08 +08:00
|
|
|
reg_ctx_sp = std::make_shared<RegisterContextDummy>(
|
|
|
|
*thread, 0, target.GetArchitecture().GetAddressByteSize());
|
2013-04-23 02:26:52 +08:00
|
|
|
}
|
2012-08-24 05:17:11 +08:00
|
|
|
return reg_ctx_sp;
|
|
|
|
}
|
|
|
|
|
|
|
|
StopInfoSP
|
|
|
|
OperatingSystemPython::CreateThreadStopReason(lldb_private::Thread *thread) {
|
|
|
|
// We should have gotten the thread stop info from the dictionary of data for
|
|
|
|
// the thread in the initial call to get_thread_info(), this should have been
|
|
|
|
// cached so we can return it here
|
|
|
|
StopInfoSP
|
|
|
|
stop_info_sp; //(StopInfo::CreateStopReasonWithSignal (*thread, SIGSTOP));
|
|
|
|
return stop_info_sp;
|
|
|
|
}
|
|
|
|
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
lldb::ThreadSP OperatingSystemPython::CreateThread(lldb::tid_t tid,
|
|
|
|
addr_t context) {
|
2013-03-28 07:08:40 +08:00
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_THREAD));
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
"OperatingSystemPython::CreateThread (tid = 0x%" PRIx64
|
|
|
|
", context = 0x%" PRIx64 ") fetching register data from python",
|
|
|
|
tid, context);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
if (m_interpreter && m_python_object_sp) {
|
Prevent deadlock in OS Plugins
Summary:
When performing a synchronous resume, the API mutex is held until the
process is stopped. This is fine, except for when the OS plugins are processing
an event before the main thread is aware of it, in which case we end up with a
deadlock because in the internal thread we acquire a resource lock first, and
then wait for the API lock, while in the main thread we do the opposite, we
already hold the API mutex but are now waiting for the event mutex to handle
the event.
This patch fixes this by relaxing the need for the API lock in the OS plugins.
We can get away with this because we now this code is executed in the main
thread. As stated in the comment above, we just want to ensure nobody else
messes with the API while we're making a change. In theory it's possible that
the main thread would release the lock while we're executing the function, but
prevent this would require a more structural solution (which we want, but do
not have today).
The same workaround was already present, but this patch generalizes it to the
whole file.
This will allow me to re-land r329891.
Reviewers: clayborg, jingham, labath
Subscribers: llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D45586
llvm-svn: 330002
2018-04-13 18:25:23 +08:00
|
|
|
// First thing we have to do is to try to get the API lock, and the
|
|
|
|
// interpreter lock. We're going to change the thread content of the
|
|
|
|
// process, and we're going to use python, which requires the API lock to
|
|
|
|
// do it. We need the interpreter lock to make sure thread_info_dict stays
|
|
|
|
// alive.
|
|
|
|
//
|
|
|
|
// If someone already has the API lock, that is ok, we just want to avoid
|
|
|
|
// external code from making new API calls while this call is happening.
|
|
|
|
//
|
|
|
|
// This is a recursive lock so we can grant it to any Python code called on
|
|
|
|
// the stack below us.
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
Target &target = m_process->GetTarget();
|
Prevent deadlock in OS Plugins
Summary:
When performing a synchronous resume, the API mutex is held until the
process is stopped. This is fine, except for when the OS plugins are processing
an event before the main thread is aware of it, in which case we end up with a
deadlock because in the internal thread we acquire a resource lock first, and
then wait for the API lock, while in the main thread we do the opposite, we
already hold the API mutex but are now waiting for the event mutex to handle
the event.
This patch fixes this by relaxing the need for the API lock in the OS plugins.
We can get away with this because we now this code is executed in the main
thread. As stated in the comment above, we just want to ensure nobody else
messes with the API while we're making a change. In theory it's possible that
the main thread would release the lock while we're executing the function, but
prevent this would require a more structural solution (which we want, but do
not have today).
The same workaround was already present, but this patch generalizes it to the
whole file.
This will allow me to re-land r329891.
Reviewers: clayborg, jingham, labath
Subscribers: llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D45586
llvm-svn: 330002
2018-04-13 18:25:23 +08:00
|
|
|
std::unique_lock<std::recursive_mutex> api_lock(target.GetAPIMutex(),
|
|
|
|
std::defer_lock);
|
2019-11-15 07:27:49 +08:00
|
|
|
(void)api_lock.try_lock(); // See above.
|
Prevent deadlock in OS Plugins
Summary:
When performing a synchronous resume, the API mutex is held until the
process is stopped. This is fine, except for when the OS plugins are processing
an event before the main thread is aware of it, in which case we end up with a
deadlock because in the internal thread we acquire a resource lock first, and
then wait for the API lock, while in the main thread we do the opposite, we
already hold the API mutex but are now waiting for the event mutex to handle
the event.
This patch fixes this by relaxing the need for the API lock in the OS plugins.
We can get away with this because we now this code is executed in the main
thread. As stated in the comment above, we just want to ensure nobody else
messes with the API while we're making a change. In theory it's possible that
the main thread would release the lock while we're executing the function, but
prevent this would require a more structural solution (which we want, but do
not have today).
The same workaround was already present, but this patch generalizes it to the
whole file.
This will allow me to re-land r329891.
Reviewers: clayborg, jingham, labath
Subscribers: llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D45586
llvm-svn: 330002
2018-04-13 18:25:23 +08:00
|
|
|
auto interpreter_lock = m_interpreter->AcquireInterpreterLock();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-03-18 04:04:04 +08:00
|
|
|
StructuredData::DictionarySP thread_info_dict =
|
|
|
|
m_interpreter->OSPlugin_CreateThread(m_python_object_sp, tid, context);
|
2014-02-14 07:34:38 +08:00
|
|
|
std::vector<bool> core_used_map;
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
if (thread_info_dict) {
|
2013-04-13 04:07:46 +08:00
|
|
|
ThreadList core_threads(m_process);
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
ThreadList &thread_list = m_process->GetThreadList();
|
|
|
|
bool did_create = false;
|
2015-03-18 04:04:04 +08:00
|
|
|
ThreadSP thread_sp(
|
|
|
|
CreateThreadFromThreadInfo(*thread_info_dict, core_threads,
|
|
|
|
thread_list, core_used_map, &did_create));
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
if (did_create)
|
|
|
|
thread_list.AddThread(thread_sp);
|
|
|
|
return thread_sp;
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
2013-01-19 07:41:08 +08:00
|
|
|
return ThreadSP();
|
|
|
|
}
|
|
|
|
|
2019-12-14 02:37:33 +08:00
|
|
|
#endif // #if LLDB_ENABLE_PYTHON
|