History log of /external/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
52ebc0aab1fdecb634801deceeddd71a14c2148c 19-Jan-2013 Greg Clayton <gclayton@apple.com> <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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@172873 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
d891f9b872103235cfd2ed452c6f14a4394d9b3a 05-Dec-2012 Daniel Malea <daniel.malea@intel.com> 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!




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169341 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
ef9eb809246491a7a9db1f2bd35d854924525ba6 11-Sep-2012 Jason Molenda <jmolenda@apple.com> Remove LLDB_DISABLE_PYTHON ifndef around FormatManager::LoadObjCFormatters() prototype,
it is unconditionally present now.

ObjectContainerBSDArchive::CreateInstance %z8.8x is not a valid printf arg specifier, %8.8zx would work
for size_t arg but this arg is addr_t. use %8.8llx and cast up to uint64_t.

ObjectFile::FindPlugin ditto.

DynamicRegisterInfo::SetRegisterInfo ifdef this function out if LLDB_DISABLE_PYTHON.




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163599 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
a63665a17f889d69384abc82311c671b9809419c 24-Aug-2012 Greg Clayton <gclayton@apple.com> We have a partially working OS plug-in through python!



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162532 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
88b980bfd735c4691b7f0771a45a78cb75033564 24-Aug-2012 Greg Clayton <gclayton@apple.com> Added Args::StringForEncoding(), Args::StringToGenericRegister() and centralized the parsing of the string to encoding and string to generic register.

Added code the initialize the register context in the OperatingSystemPython plug-in with the new PythonData classes, and added a test OperatingSystemPython module in lldb/examples/python/operating_system.py that we can use for testing.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162530 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
37f962e785be99dc4f0c5e9d02416992ff03bbd0 22-Aug-2011 Greg Clayton <gclayton@apple.com> Added a new plug-in type: lldb_private::OperatingSystem. The operating system
plug-ins are add on plug-ins for the lldb_private::Process class that can add
thread contexts that are read from memory. It is common in kernels to have
a lot of threads that are not currently executing on any cores (JTAG debugging
also follows this sort of thing) and are context switched out whose state is
stored in memory data structures. Clients can now subclass the OperatingSystem
plug-ins and then make sure their Create functions correcltly only enable
themselves when the right binary/target triple are being debugged. The
operating system plug-ins get a chance to attach themselves to processes just
after launching or attaching and are given a lldb_private::Process object
pointer which can be inspected to see if the main executable, target triple,
or any shared libraries match a case where the OS plug-in should be used.
Currently the OS plug-ins can create new threads, define the register contexts
for these threads (which can all be different if desired), and populate and
manage the thread info (stop reason, registers in the register context) as
the debug session goes on.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@138228 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.cpp