maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp

423 lines
16 KiB
C++
Raw Normal View History

Don't allow direct access to StreamString's internal buffer. This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
2016-11-17 05:15:24 +08:00
//===-- OperatingSystemPython.cpp --------------------------------*- C++-*-===//
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
//
// 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
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
#ifndef LLDB_DISABLE_PYTHON
#include "OperatingSystemPython.h"
// C Includes
// C++ Includes
// Other libraries and framework includes
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
#include "Plugins/Process/Utility/DynamicRegisterInfo.h"
#include "Plugins/Process/Utility/RegisterContextDummy.h"
#include "Plugins/Process/Utility/RegisterContextMemory.h"
#include "Plugins/Process/Utility/ThreadMemory.h"
Adding bindings to the Script Interpreter for some basic Python OS plugin functionality (still WIP) llvm-svn: 162513
2012-08-24 08:30:47 +08:00
#include "lldb/Core/Debugger.h"
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
#include "lldb/Core/Module.h"
#include "lldb/Core/PluginManager.h"
#include "lldb/Core/ValueObjectVariable.h"
Adding bindings to the Script Interpreter for some basic Python OS plugin functionality (still WIP) llvm-svn: 162513
2012-08-24 08:30:47 +08:00
#include "lldb/Interpreter/CommandInterpreter.h"
Remove ScriptInterpreterObject. This removes ScriptInterpreterObject from the codebase completely. Places that used to rely on ScriptInterpreterObject now use StructuredData::Object and its derived classes. To support this, a new type of StructuredData object is introduced, called StructuredData::Generic, which stores a void*. Internally within the python library, StructuredPythonObject subclasses this StructuredData::Generic class so that it can addref and decref the python object on construction and destruction. Additionally, all of the classes in PythonDataObjects.h such as PythonList, PythonDictionary, etc now provide a method to create an instance of the corresponding StructuredData type. For example, there is PythonDictionary::CreateStructuredDictionary. To eliminate dependencies on PythonDataObjects for external callers, all ScriptInterpreter methods now return only StructuredData classes The rest of the changes in this CL are focused on fixing up users of PythonDataObjects classes to use the new StructuredData classes. llvm-svn: 232534
2015-03-18 04:04:04 +08:00
#include "lldb/Interpreter/ScriptInterpreter.h"
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
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"
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
#include "lldb/Target/ThreadList.h"
Move DataBuffer / DataExtractor and friends from Core -> Utility. llvm-svn: 296943
2017-03-04 09:30:05 +08:00
#include "lldb/Utility/DataBufferHeap.h"
Move RegisterValue,Scalar,State from Core to Utility These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
2018-08-07 19:07:21 +08:00
#include "lldb/Utility/RegisterValue.h"
Move classes from Core -> Utility. This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
2017-02-03 05:39:50 +08:00
#include "lldb/Utility/StreamString.h"
Move StructuredData from Core to Utility Summary: It had a dependency on StringConvert and file reading code, which is not in Utility. I've replaced that code by equivalent llvm operations. I've added a unit test to demonstrate that parsing a file still works. Reviewers: zturner, jingham Subscribers: kubamracek, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D34625 llvm-svn: 306394
2017-06-27 18:45:31 +08:00
#include "lldb/Utility/StructuredData.h"
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
using namespace lldb;
using namespace lldb_private;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
void OperatingSystemPython::Initialize() {
PluginManager::RegisterPlugin(GetPluginNameStatic(),
GetPluginDescriptionStatic(), CreateInstance,
nullptr);
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
void OperatingSystemPython::Terminate() {
PluginManager::UnregisterPlugin(CreateInstance);
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
OperatingSystem *OperatingSystemPython::CreateInstance(Process *process,
bool force) {
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// Python OperatingSystem plug-ins must be requested by name, so force must
// be true
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
FileSpec python_os_plugin_spec(process->GetPythonOSPluginPath());
if (python_os_plugin_spec && python_os_plugin_spec.Exists()) {
std::unique_ptr<OperatingSystemPython> os_ap(
new OperatingSystemPython(process, python_os_plugin_spec));
if (os_ap.get() && os_ap->IsValid())
return os_ap.release();
}
return NULL;
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
ConstString OperatingSystemPython::GetPluginNameStatic() {
static ConstString g_name("python");
return g_name;
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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.";
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
OperatingSystemPython::OperatingSystemPython(lldb_private::Process *process,
const FileSpec &python_module_path)
: OperatingSystem(process), m_thread_list_valobj_sp(), m_register_info_ap(),
m_interpreter(NULL), m_python_object_sp() {
if (!process)
return;
TargetSP target_sp = process->CalculateTarget();
if (!target_sp)
return;
m_interpreter =
target_sp->GetDebugger().GetCommandInterpreter().GetScriptInterpreter();
if (m_interpreter) {
std::string os_plugin_class_name(
python_module_path.GetFilename().AsCString(""));
if (!os_plugin_class_name.empty()) {
const bool init_session = false;
const bool allow_reload = true;
char python_module_path_cstr[PATH_MAX];
python_module_path.GetPath(python_module_path_cstr,
sizeof(python_module_path_cstr));
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 12:51:55 +08:00
Status error;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (m_interpreter->LoadScriptingModule(
python_module_path_cstr, allow_reload, init_session, error)) {
// 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";
StructuredData::ObjectSP object_sp =
m_interpreter->OSPlugin_CreatePluginObject(
os_plugin_class_name.c_str(), process->CalculateProcess());
if (object_sp && object_sp->IsValid())
m_python_object_sp = object_sp;
}
Adding bindings to the Script Interpreter for some basic Python OS plugin functionality (still WIP) llvm-svn: 162513
2012-08-24 08:30:47 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
OperatingSystemPython::~OperatingSystemPython() {}
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
DynamicRegisterInfo *OperatingSystemPython::GetDynamicRegisterInfo() {
if (m_register_info_ap.get() == NULL) {
if (!m_interpreter || !m_python_object_sp)
return NULL;
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_OS));
if (log)
log->Printf("OperatingSystemPython::GetDynamicRegisterInfo() fetching "
"thread register definitions from python for pid %" PRIu64,
m_process->GetID());
StructuredData::DictionarySP dictionary =
m_interpreter->OSPlugin_RegisterInfo(m_python_object_sp);
if (!dictionary)
return NULL;
m_register_info_ap.reset(new DynamicRegisterInfo(
*dictionary, m_process->GetTarget().GetArchitecture()));
assert(m_register_info_ap->GetNumRegisters() > 0);
assert(m_register_info_ap->GetNumRegisterSets() > 0);
}
return m_register_info_ap.get();
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
}
//------------------------------------------------------------------
// PluginInterface protocol
//------------------------------------------------------------------
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
ConstString OperatingSystemPython::GetPluginName() {
return GetPluginNameStatic();
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
uint32_t OperatingSystemPython::GetPluginVersion() { return 1; }
bool OperatingSystemPython::UpdateThreadList(ThreadList &old_thread_list,
ThreadList &core_thread_list,
ThreadList &new_thread_list) {
if (!m_interpreter || !m_python_object_sp)
return false;
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_OS));
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.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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.
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);
api_lock.try_lock();
auto interpreter_lock = m_interpreter->AcquireInterpreterLock();
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (log)
log->Printf("OperatingSystemPython::UpdateThreadList() fetching thread "
"data from python for pid %" PRIu64,
m_process->GetID());
// The threads that are in "new_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.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
StructuredData::ArraySP threads_list =
m_interpreter->OSPlugin_ThreadsInfo(m_python_object_sp);
const uint32_t num_cores = core_thread_list.GetSize(false);
// Make a map so we can keep track of which cores were used from the
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
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".
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
std::vector<bool> core_used_map(num_cores, false);
if (threads_list) {
if (log) {
StreamString strm;
threads_list->Dump(strm);
Don't allow direct access to StreamString's internal buffer. This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
2016-11-17 05:15:24 +08:00
log->Printf("threads_list = %s", strm.GetData());
The OS plug-in can now get data from a python script that implements the protocol. llvm-svn: 162540
2012-08-24 13:45:15 +08:00
}
Fixed deadlocks that could occur when using python for breakpoints, operating system plugins, and other async python usage. <rdar://problem/16054348> <rdar://problem/16040833> llvm-svn: 201372
2014-02-14 07:34:38 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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()) {
ThreadSP thread_sp(
CreateThreadFromThreadInfo(*thread_dict, core_thread_list,
old_thread_list, core_used_map, NULL));
if (thread_sp)
new_thread_list.AddThread(thread_sp);
}
Fixed deadlocks that could occur when using python for breakpoints, operating system plugins, and other async python usage. <rdar://problem/16054348> <rdar://problem/16040833> llvm-svn: 201372
2014-02-14 07:34:38 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// beginning of the list
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
uint32_t insert_idx = 0;
for (uint32_t core_idx = 0; core_idx < num_cores; ++core_idx) {
if (core_used_map[core_idx] == false) {
new_thread_list.InsertThread(
core_thread_list.GetThreadAtIndex(core_idx, false), insert_idx);
++insert_idx;
}
}
Changed the formerly pure virtual function: namespace lldb_private { class Thread { virtual lldb::StopInfoSP GetPrivateStopReason() = 0; }; } To not be virtual. The lldb_private::Thread now handles the correct caching and will call a new pure virtual function: namespace lldb_private { class Thread { virtual bool CalculateStopInfo() = 0; } } This function must be overridden by thead lldb_private::Thread subclass and the only thing it needs to do is to set the Thread::StopInfo() with the current stop reason and return true, or return false if there is no stop reason. The lldb_private::Thread class will take care of calling this function only when it is required. This allows lldb_private::Thread subclasses to be a bit simpler and not all need to duplicate the cache and invalidation settings. Also renamed: lldb::StopInfoSP lldb_private::Thread::GetPrivateStopReason(); To: lldb::StopInfoSP lldb_private::Thread::GetPrivateStopInfo(); Also cleaned up a case where the ThreadPlanStepOverBreakpoint might not re-set its breakpoint if the thread disappears (which was happening due to a bug when using the OperatingSystem plug-ins with memory threads and real threads). llvm-svn: 181501
2013-05-09 09:55:29 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
return new_thread_list.GetSize(false) > 0;
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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();
Remove ScriptInterpreterObject. This removes ScriptInterpreterObject from the codebase completely. Places that used to rely on ScriptInterpreterObject now use StructuredData::Object and its derived classes. To support this, a new type of StructuredData object is introduced, called StructuredData::Generic, which stores a void*. Internally within the python library, StructuredPythonObject subclasses this StructuredData::Generic class so that it can addref and decref the python object on construction and destruction. Additionally, all of the classes in PythonDataObjects.h such as PythonList, PythonDictionary, etc now provide a method to create an instance of the corresponding StructuredData type. For example, there is PythonDictionary::CreateStructuredDictionary. To eliminate dependencies on PythonDataObjects for external callers, all ScriptInterpreter methods now return only StructuredData classes The rest of the changes in this CL are focused on fixing up users of PythonDataObjects classes to use the new StructuredData classes. llvm-svn: 232534
2015-03-18 04:04:04 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
uint32_t core_number;
addr_t reg_data_addr;
Update StructuredData::String to return StringRefs. It was returning const std::string& which was leading to unnecessary copies all over the place, and preventing people from doing things like Dict->GetValueForKeyAsString("foo", ref); llvm-svn: 302875
2017-05-12 13:49:54 +08:00
llvm::StringRef name;
llvm::StringRef queue;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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);
// 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
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// operating system threads, clear the thread so we create an operating
// system thread for this.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
thread_sp.reset();
Remove ScriptInterpreterObject. This removes ScriptInterpreterObject from the codebase completely. Places that used to rely on ScriptInterpreterObject now use StructuredData::Object and its derived classes. To support this, a new type of StructuredData object is introduced, called StructuredData::Generic, which stores a void*. Internally within the python library, StructuredPythonObject subclasses this StructuredData::Generic class so that it can addref and decref the python object on construction and destruction. Additionally, all of the classes in PythonDataObjects.h such as PythonList, PythonDictionary, etc now provide a method to create an instance of the corresponding StructuredData type. For example, there is PythonDictionary::CreateStructuredDictionary. To eliminate dependencies on PythonDataObjects for external callers, all ScriptInterpreter methods now return only StructuredData classes The rest of the changes in this CL are focused on fixing up users of PythonDataObjects classes to use the new StructuredData classes. llvm-svn: 232534
2015-03-18 04:04:04 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
if (!thread_sp) {
if (did_create_ptr)
*did_create_ptr = true;
Update StructuredData::String to return StringRefs. It was returning const std::string& which was leading to unnecessary copies all over the place, and preventing people from doing things like Dict->GetValueForKeyAsString("foo", ref); llvm-svn: 302875
2017-05-12 13:49:54 +08:00
thread_sp.reset(
new ThreadMemory(*m_process, tid, name, queue, reg_data_addr));
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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;
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
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
return 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
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
void OperatingSystemPython::ThreadWasSelected(Thread *thread) {}
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
RegisterContextSP
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
OperatingSystemPython::CreateRegisterContextForThread(Thread *thread,
addr_t reg_data_addr) {
RegisterContextSP reg_ctx_sp;
if (!m_interpreter || !m_python_object_sp || !thread)
return reg_ctx_sp;
Take the Target API lock before letting the Python code start to work constructing threads, otherwise we will risk a lock-inversion deadlock between the thread list and the API mutex. <rdar://problem/12554049> llvm-svn: 169612
2012-12-08 01:42:15 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (!IsOperatingSystemPluginThread(thread->shared_from_this()))
return reg_ctx_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.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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);
api_lock.try_lock();
auto interpreter_lock = m_interpreter->AcquireInterpreterLock();
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_THREAD));
if (reg_data_addr != LLDB_INVALID_ADDRESS) {
// The registers data is in contiguous memory, just create the register
// context using the address provided
if (log)
log->Printf("OperatingSystemPython::CreateRegisterContextForThread (tid "
"= 0x%" PRIx64 ", 0x%" PRIx64 ", reg_data_addr = 0x%" PRIx64
") creating memory register context",
thread->GetID(), thread->GetProtocolID(), reg_data_addr);
reg_ctx_sp.reset(new RegisterContextMemory(
*thread, 0, *GetDynamicRegisterInfo(), reg_data_addr));
} else {
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
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
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (log)
log->Printf("OperatingSystemPython::CreateRegisterContextForThread (tid "
"= 0x%" PRIx64 ", 0x%" PRIx64
") fetching register data from python",
thread->GetID(), thread->GetProtocolID());
StructuredData::StringSP reg_context_data =
m_interpreter->OSPlugin_RegisterContextData(m_python_object_sp,
thread->GetID());
if (reg_context_data) {
std::string value = reg_context_data->GetValue();
DataBufferSP data_sp(new DataBufferHeap(value.c_str(), value.length()));
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);
The OS plug-in can now get data from a python script that implements the protocol. llvm-svn: 162540
2012-08-24 13:45:15 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
The OS plug-in can now get data from a python script that implements the protocol. llvm-svn: 162540
2012-08-24 13:45:15 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
// if we still have no register data, fallback on a dummy context to avoid
// crashing
if (!reg_ctx_sp) {
if (log)
log->Printf("OperatingSystemPython::CreateRegisterContextForThread (tid "
"= 0x%" PRIx64 ") forcing a dummy register context",
thread->GetID());
reg_ctx_sp.reset(new RegisterContextDummy(
*thread, 0, target.GetArchitecture().GetAddressByteSize()));
}
return reg_ctx_sp;
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
}
StopInfoSP
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
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;
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
lldb::ThreadSP OperatingSystemPython::CreateThread(lldb::tid_t tid,
addr_t context) {
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_THREAD));
if (log)
log->Printf("OperatingSystemPython::CreateThread (tid = 0x%" PRIx64
", context = 0x%" PRIx64 ") fetching register data from python",
tid, context);
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.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +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);
api_lock.try_lock();
auto interpreter_lock = m_interpreter->AcquireInterpreterLock();
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
StructuredData::DictionarySP thread_info_dict =
m_interpreter->OSPlugin_CreateThread(m_python_object_sp, tid, context);
std::vector<bool> core_used_map;
if (thread_info_dict) {
ThreadList core_threads(m_process);
ThreadList &thread_list = m_process->GetThreadList();
bool did_create = false;
ThreadSP thread_sp(
CreateThreadFromThreadInfo(*thread_info_dict, core_threads,
thread_list, core_used_map, &did_create));
if (did_create)
thread_list.AddThread(thread_sp);
return 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
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
return ThreadSP();
<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
}
Added a hollowed out version of an OperatingSystem plugin that will use a class in python to get thread information for threads stored in memory. llvm-svn: 162472
2012-08-24 05:17:11 +08:00
#endif // #ifndef LLDB_DISABLE_PYTHON