History log of /external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
95c25e4134db08078cee4098c7bedd3254a18b23 30-May-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13956179>

Cleaned up the thread updating code in the OperatingSystemPython class. It doesn't need to clear the "new_thread_list" anymore as it is always empty.

It also now assigns the "core_thread_list" to "new_thread_list" if no threads are detected through python.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182893 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
e15e58facd4814a2be1cc1aa385e9f9125b92993 23-May-2013 Greg Clayton <gclayton@apple.com> Added a new "lldb" log channel named "os" for the OperatingSystem plug-ins to use.

Added logging for the OS plug-in python objects in OperatingSystemPython so we can see the python dictionary returned from the plug-in when logging is enabled.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182530 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
0e191607adcb0ea8ebd06c278be648a7f5c0097f 10-May-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13854277>
<rdar://problem/13594769>

Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging

The plug-in interface changes:

Modified the lldb_private::PluginInterface class that all plug-ins inherit from:

Changed:

virtual const char * GetPluginName() = 0;

To:

virtual ConstString GetPluginName() = 0;

Removed:

virtual const char * GetShortPluginName() = 0;

- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names.
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.






git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181631 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
863aa28adf536c9c008e1590f25da662431d6f13 09-May-2013 Greg Clayton <gclayton@apple.com> 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).



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181501 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
4e75e3533bddc7cf7264c6c7f7b4d812d4466e96 07-May-2013 Andrew Kaylor <andrew.kaylor@intel.com> Reinstating r181091 and r181106 with fix for Linux regressions.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181340 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
95bea1dfb166a1816ee36a3453aa3ebeca248844 07-May-2013 Ashok Thirumurthi <ashok.thirumurthi@intel.com> Temporarily reverting r181091 and r181106 due to the vast test breakage on the Linux buildbots
while we develop a better understanding of how to manage the thread lists in a platform-independant fashion.

Reviewed by: Daniel Malea


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181323 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
7bee8abf1678cb4dade06add9036981f7249ba09 04-May-2013 Greg Clayton <gclayton@apple.com> After recent OperatingsSystem plug-in changes, the lldb_private::Process and lldb_private::Thread subclasses were changed and the API was not respected properly.

This checkin aims to fix this. The process now has two thread lists: a real thread list for threads that are created by the lldb_private::Process subclass, and the user visible threads. The user visible threads are the same as the real threas when no OS plug-in in used. But when an OS plug-in is used, the user thread can be a combination of real and "memory" threads. Real threads can be placed inside of memory threads so that a thread appears to be different, but is still controlled by the actual real thread. When the thread list needs updating, the lldb_private::Process class will call the: lldb_private::Process::UpdateThreadList() function with the old real thread list, and the function is expected to fill in the new real thread list with the current state of the process. After this function, the process will check if there is an OS plug-in being used, and if so, it will give the old user thread list, the new real thread list and the OS plug-in will create the new user thread list from both of these lists. If there is no OS plug-in, the real thread list is the user thread list.

These changes keep the lldb_private::Process subclasses clean and no changes are required.




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181091 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
a46013bde54626b68cd2013b108f73a205f4b29a 01-May-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13700260>
<rdar://problem/13723772>

Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves.

A few things are introduced:
- lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread.
- Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification.
- Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them
- Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180886 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
49ff4e6008bdeb28de57fa4c931aeb8cc67152d4 22-Apr-2013 Enrico Granata <egranata@apple.com> <rdar://problem/13590152>

Providing a dummy RegisterContext to secure against faulty Python OS plugins that do not return a valid RegisterContext
The RegisterContextDummy exports a PC with a constant 0xFFFFFFFFFFFFFFFF value



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180033 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
102b2c2681c9a830afe25bfea35557421905e42c 19-Apr-2013 Greg Clayton <gclayton@apple.com> After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179805 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
81a96aa6242f7b559770f5dc62316253cb8cb0d4 18-Apr-2013 Greg Clayton <gclayton@apple.com> Since we use C++11, we should switch over to using std::unique_ptr when C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++.

Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179779 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
2e8c97665abcedc0feaa86f8ebb342e2084ec3e8 16-Apr-2013 Greg Clayton <gclayton@apple.com> Remove a debug print statement that I left in.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179623 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
9acf3699d2bea583b45c762f4cd82b2a4af6131b 12-Apr-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13491977>

Made some fixes to the OperatingSystemPython class:
- If any thread dictionary contains any "core=N" key/value pairs then the threads obtained from the lldb_private::Process itself will be placed inside the ThreadMemory threads and will be used to get the information for a thread.
- Cleaned up all the places where a thread inside a thread was causing problems



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179405 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
989c6f74bad9acb7580025c1fc35378799c28e43 28-Mar-2013 Enrico Granata <egranata@apple.com> <rdar://problem/13412986>

Holding the Python lock while we call the Python C API to post-process objects returned from the OS plugins
This should avoid issues where some Python objects get invalidated while we are in the middle of processing them and we end up with an invalid Python state and a crash

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178206 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
952e9dc874944fcdbbb224f3ec4fc2c859376f64 28-Mar-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13521159>

LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178191 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
36da2aa6dc5ad9994b638ed09eb81c44cc05540b 25-Jan-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13069948>

Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.

So I defined a new "lldb::offset_t" which should be used for all file offsets.

After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.

Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@173463 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
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/OperatingSystem/Python/OperatingSystemPython.cpp
b9db9d5bb01963774f28540dbe2c5a11f586ff29 07-Dec-2012 Daniel Malea <daniel.malea@intel.com> Fix a few more clang (3.2) warnings on Linux:
- remove unused members
- add NO_PEDANTIC to selected Makefiles
- fix return values (removed NULL as needed)
- disable warning about four-char-constants
- remove unneeded const from operator*() declaration
- add missing lambda function return types
- fix printf() with no format string
- change sizeof to use a type name instead of variable name
- fix Linux ProcessMonitor.cpp to be 32/64 bit friendly
- disable warnings emitted by swig-generated C++ code

Patch by Matt Kopec!



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169645 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
4a96ab8a1d4e2222b9f6e415b97bde6b826f94a4 07-Dec-2012 Jim Ingham <jingham@apple.com> 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>

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169612 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.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/OperatingSystem/Python/OperatingSystemPython.cpp
5f35a4be95aed0e5b2cb36f7d785bcbfc67284ae 29-Nov-2012 Daniel Malea <daniel.malea@intel.com> Resolve printf formatting warnings on Linux:
- use macros from inttypes.h for format strings instead of OS-specific types

Patch from Matt Kopec!



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168945 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
91a9f2127fa8b8e90f6ea1676d11f97f44ce22dd 25-Oct-2012 Greg Clayton <gclayton@apple.com> Allow operating system plug-ins to specify the address for registers so we don't have to create data up front.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166701 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
467e1ea328873763db41d47196b4ecd56cdde11b 24-Oct-2012 Greg Clayton <gclayton@apple.com> Added process and thread logging the python OperatingSystem plug-in.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166608 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
2e7f313dc473b036788319690116b324cb44b765 19-Oct-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/12491420>

Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting:

settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py

Then run your program and see the extra threads.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166244 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
94a5d0de4433dce556db59758f3d6124eb0e1a2a 10-Oct-2012 Jim Ingham <jingham@apple.com> Change the Thread constructor over to take a Process& rather than a ProcessSP. We can't create Threads with a NULL ProcessSP, so it makes no sense to use the SP.
Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame
changes the stack.
Made the Driver use this notification to print the new thread status rather than doing it in the command.
Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call.

<rdar://problem/12383087>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@165640 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
915da3534f6024d9983e0ba94142936df8745562 28-Aug-2012 Filipe Cabecinhas <me@filcab.net> Fixes by Daniel Malea.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162756 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
e1cedffeba2cbd3444e5bbcbe2f7febbe27e0c6f 24-Aug-2012 Greg Clayton <gclayton@apple.com> Remove printf that go left in the code.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162542 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
b8f126a807c00e5c2d0e7faaf764c38072cd6764 24-Aug-2012 Greg Clayton <gclayton@apple.com> The OS plug-in can now get data from a python script that implements the protocol.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162540 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.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/OperatingSystem/Python/OperatingSystemPython.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/OperatingSystem/Python/OperatingSystemPython.cpp
cec963a709ec4fa099ea44a8abe67639c5fb8abe 24-Aug-2012 Enrico Granata <egranata@apple.com> Fixing a bunch of issues with the OS plugin code

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162527 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
3e85b6378d312866ab25eb5623d9b8253bc498f8 24-Aug-2012 Enrico Granata <egranata@apple.com> Hooking up two more calls for the PythonOSPlugin stuff. The part of code to fetch the data and convert it to C++ objects is still missing, but will come

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162522 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
658c5c239f71452c86dfffa3f4c370f517305bc0 24-Aug-2012 Enrico Granata <egranata@apple.com> Was forcing everyone on ToT to use the PythonOSPlugin.. my bad

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162519 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
155ee91cc315888c26de1bfebd876bf35b857329 24-Aug-2012 Enrico Granata <egranata@apple.com> Adding bindings to the Script Interpreter for some basic Python OS plugin functionality (still WIP)

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162513 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
d815ded12b0c9fea2c8a38cc241d3609b3fe228a 23-Aug-2012 Greg Clayton <gclayton@apple.com> 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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162472 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp