summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/OperatingSystem/Python
Commit message (Collapse)AuthorAgeFilesLines
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-062-417/+401
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-191-8/+8
| | | | llvm-svn: 270024
* Remove autoconf support from source directories.Eugene Zelenko2016-01-281-14/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* Fix Clang-tidy modernize-use-override warnings in some files in ↵Eugene Zelenko2015-10-211-31/+29
| | | | | | | | source/Plugins; other minor fixes. Differential Revision: http://reviews.llvm.org/D13951 llvm-svn: 250925
* Add an OperatingSystem plugin to support goroutinesRyan Brown2015-09-161-3/+1
| | | | | | | | | | The Go runtime schedules user level threads (goroutines) across real threads. This adds an OS plugin to create memory threads for goroutines. It supports the 1.4 and 1.5 go runtime. Differential Revision: http://reviews.llvm.org/D5871 llvm-svn: 247852
* [cmake] Remove LLVM_NO_RTTI.Bruce Mitchener2015-09-031-2/+0
| | | | | | | | | | | | | | Summary: This doesn't exist in other LLVM projects any longer and doesn't do anything. Reviewers: chaoren, labath Subscribers: emaste, tberghammer, lldb-commits, danalbert Differential Revision: http://reviews.llvm.org/D12586 llvm-svn: 246749
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-241-1/+0
| | | | | | | | | | | | | | | | | | | | lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
* [Makefiles] Align library names with CMake buildKeno Fischer2015-07-141-3/+3
| | | | | | | | | | | | Summary: This aligns the library names used by the Makefile build to be the same as those create by the CMake build to make switching between the two easier. The only major difficulty was lldbHost which was one library in the CMake system and several in the Makefile system. Most of the other changes are trivial renames. Reviewers: labath Subscribers: emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11154 llvm-svn: 242196
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-2/+0
| | | | | | | | | | | | | Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
* Added XML to the host layer.Greg Clayton2015-05-261-1/+1
| | | | | | | | | | | | We know have on API we should use for all XML within LLDB in XML.h. This API will be easy back the XML parsing by different libraries in case libxml2 doesn't work on all platforms. It also allows the only place for #ifdef ...XML... to be in XML.h and XML.cpp. The API is designed so it will still compile with or without XML support and there is a static function "bool XMLDocument::XMLEnabled()" that can be called to see if XML is currently supported. All APIs will return errors, false, or nothing when XML isn't enabled. Converted all locations that used XML over to using the host XML implementation. Added target.xml support to debugserver. Extended the XML register format to work for LLDB by including extra attributes and elements where needed. This allows the target.xml to replace the qRegisterInfo packets and allows us to fetch all register info in a single packet. <rdar://problem/21090173> llvm-svn: 238224
* Fix stepping a virtual thread when the python operating system was enabled.Greg Clayton2015-04-071-4/+11
| | | | | | | | | | | | The OperatingSystem plug-ins allow code to detect threads in memory and then say "memory thread 0x11111" is backed by the actual thread 1. You can then single step these virtual threads. A problem arose when thread specific breakpoints were used during thread plans where we would say "set a breakpoint on thread 0x11111" and we would hit the breakpoint on the real thread 1 and the thread IDs wouldn't match and we would get rid of the "stopped at breakpoint" stop info due to this mismatch. Code was added to ensure these events get forwarded and thus allow single stepping a memory thread to work correctly. Added a test case for this as well. <rdar://problem/19211770> llvm-svn: 234364
* Remove ScriptInterpreterObject.Zachary Turner2015-03-172-103/+87
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fixed deadlocks that could occur when using python for breakpoints, ↵Greg Clayton2014-02-132-7/+29
| | | | | | | | | operating system plugins, and other async python usage. <rdar://problem/16054348> <rdar://problem/16040833> llvm-svn: 201372
* <rdar://problem/14972424>Greg Clayton2013-10-171-1/+1
| | | | | | | | | | | | | | | - Made the dynamic register context for the GDB remote plug-in inherit from the generic DynamicRegisterInfo to avoid code duplication - Finished up the target definition python setting stuff. - Added a new "slice" key/value pair that can specify that a register is part of another register: { 'name':'eax', 'set':0, 'bitsize':32, 'encoding':eEncodingUint, 'format':eFormatHex, 'slice': 'rax[31:0]' }, - Added a new "composite" key/value pair that can specify that a register is made up of two or more registers: { 'name':'d0', 'set':0, 'bitsize':64 , 'encoding':eEncodingIEEE754, 'format':eFormatFloat, 'composite': ['s1', 's0'] }, - Added a new "invalidate-regs" key/value pair for when a register is modified, it can invalidate other registers: { 'name':'cpsr', 'set':0, 'bitsize':32 , 'encoding':eEncodingUint, 'format':eFormatHex, 'invalidate-regs': ['r8', 'r9', 'r10', 'r11', 'r12', 'r13', 'r14', 'r15']}, This now completes the feature that allows a GDB remote target to completely describe itself. llvm-svn: 192858
* <rdar://problem/13956179>Greg Clayton2013-05-291-16/+3
| | | | | | | | 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. llvm-svn: 182893
* Added a new "lldb" log channel named "os" for the OperatingSystem plug-ins ↵Greg Clayton2013-05-221-2/+9
| | | | | | | | 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. llvm-svn: 182530
* <rdar://problem/13854277>Greg Clayton2013-05-102-14/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <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. llvm-svn: 181631
* Changed the formerly pure virtual function:Greg Clayton2013-05-091-20/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Reinstating r181091 and r181106 with fix for Linux regressions.Andrew Kaylor2013-05-072-4/+5
| | | | llvm-svn: 181340
* Temporarily reverting r181091 and r181106 due to the vast test breakage on ↵Ashok Thirumurthi2013-05-072-5/+4
| | | | | | | | | | 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 llvm-svn: 181323
* After recent OperatingsSystem plug-in changes, the lldb_private::Process and ↵Greg Clayton2013-05-042-4/+5
| | | | | | | | | | 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. llvm-svn: 181091
* <rdar://problem/13700260>Greg Clayton2013-05-011-6/+40
| | | | | | | | | | | | | | <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. llvm-svn: 180886
* <rdar://problem/13590152>Enrico Granata2013-04-221-0/+8
| | | | | | | 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 llvm-svn: 180033
* After discussing with Chris Lattner, we require C++11, so lets get rid of ↵Greg Clayton2013-04-182-2/+2
| | | | | | the macros and just use C++11. llvm-svn: 179805
* Since we use C++11, we should switch over to using std::unique_ptr when ↵Greg Clayton2013-04-182-2/+2
| | | | | | | | 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. llvm-svn: 179779
* Remove a debug print statement that I left in.Greg Clayton2013-04-161-2/+0
| | | | llvm-svn: 179623
* <rdar://problem/13491977>Greg Clayton2013-04-122-7/+42
| | | | | | | | 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 llvm-svn: 179405
* <rdar://problem/13412986>Enrico Granata2013-03-281-0/+3
| | | | | | | 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 llvm-svn: 178206
* <rdar://problem/13521159>Greg Clayton2013-03-271-4/+4
| | | | | | | | 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. llvm-svn: 178191
* Adding CMake build system to LLDB. Some known issues remain:Daniel Malea2013-02-211-0/+5
| | | | | | | | | | | | | | - generate-vers.pl has to be called by cmake to generate the version number - parallel builds not yet supported; dependency on clang must be explicitly specified Tested on Linux. - Building on Mac will require code-signing logic to be implemented. - Building on Windows will require OS-detection logic and some selective directory inclusion Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir who ported them to Linux! llvm-svn: 175795
* <rdar://problem/13069948>Greg Clayton2013-01-251-22/+25
| | | | | | | | | | | | 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. llvm-svn: 173463
* <rdar://problem/13010007>Greg Clayton2013-01-182-63/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix a few more clang (3.2) warnings on Linux:Daniel Malea2012-12-071-2/+2
| | | | | | | | | | | | | | | | | - 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! llvm-svn: 169645
* Take the Target API lock before letting the Python code start to work ↵Jim Ingham2012-12-071-0/+12
| | | | | | | | constructing threads, otherwise we will risk a lock-inversion deadlock between the thread list and the API mutex. <rdar://problem/12554049> llvm-svn: 169612
* Fix Linux build warnings due to redefinition of macros:Daniel Malea2012-12-051-0/+3
| | | | | | | | | - 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
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-4/+4
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* Allow operating system plug-ins to specify the address for registers so we ↵Greg Clayton2012-10-252-22/+39
| | | | | | don't have to create data up front. llvm-svn: 166701
* Added process and thread logging the python OperatingSystem plug-in.Greg Clayton2012-10-241-1/+17
| | | | llvm-svn: 166608
* <rdar://problem/12491420>Greg Clayton2012-10-182-14/+38
| | | | | | | | | | 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. llvm-svn: 166244
* Change the Thread constructor over to take a Process& rather than a ↵Jim Ingham2012-10-101-1/+1
| | | | | | | | | | | | | 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> llvm-svn: 165640
* Fixes by Daniel Malea.Filipe Cabecinhas2012-08-281-2/+2
| | | | llvm-svn: 162756
* Remove printf that go left in the code.Greg Clayton2012-08-241-1/+0
| | | | llvm-svn: 162542
* The OS plug-in can now get data from a python script that implements the ↵Greg Clayton2012-08-241-36/+66
| | | | | | protocol. llvm-svn: 162540
* We have a partially working OS plug-in through python!Greg Clayton2012-08-241-4/+4
| | | | llvm-svn: 162532
* Added Args::StringForEncoding(), Args::StringToGenericRegister() and ↵Greg Clayton2012-08-241-69/+20
| | | | | | | | 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. llvm-svn: 162530
* Fixing a bunch of issues with the OS plugin codeEnrico Granata2012-08-241-1/+1
| | | | llvm-svn: 162527
* Hooking up two more calls for the PythonOSPlugin stuff. The part of code to ↵Enrico Granata2012-08-241-4/+24
| | | | | | fetch the data and convert it to C++ objects is still missing, but will come llvm-svn: 162522
* Was forcing everyone on ToT to use the PythonOSPlugin.. my badEnrico Granata2012-08-241-1/+1
| | | | llvm-svn: 162519
* Adding bindings to the Script Interpreter for some basic Python OS plugin ↵Enrico Granata2012-08-242-11/+33
| | | | | | functionality (still WIP) llvm-svn: 162513
* Fix a typo.Johnny Chen2012-08-241-1/+1
| | | | llvm-svn: 162510
OpenPOWER on IntegriCloud