summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ScriptInterpreter/Python
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix a bug in PythonExceptionState and add unittest coverage.Zachary Turner2015-11-132-0/+13
| | | | | | | I forgot to reset the restore flag when calling member function `Acquire`. The newly added unittest should cover this case. llvm-svn: 253002
* Introduce a `PythonExceptionState` class.Zachary Turner2015-11-134-85/+263
| | | | | | | | | | | | This is a helper class which supports a number of features including exception to string formatting with backtrace handling and auto-restore of exception state upon scope exit. Additionally, unit tests are included to verify the feature set of the class. llvm-svn: 252994
* Fix non-Windows build after r252906.Zachary Turner2015-11-122-3/+3
| | | | llvm-svn: 252909
* Begin converting uses of PyCallable to PythonCallable.Zachary Turner2015-11-122-15/+49
| | | | | | | | | | | | | | | | PyCallable is a class that exists solely within the swig wrapper code. PythonCallable is a more generic implementation of the same idea that can be used by any Python-related interop code, and lives in PythonDataObjects.h The CL is mostly mechanical, and it doesn't cover every possible user of PyCallable, because I want to minimize the impact of this change (as well as making it easier to figure out what went wrong in case this causes a failure). I plan to finish up the rest of the changes in a subsequent patch, culminating in the removal of PyCallable entirely. llvm-svn: 252906
* Create `PythonTuple` and `PythonCallable` wrapper classes.Zachary Turner2015-11-112-6/+322
| | | | | | | | | | | | | | This adds PythonTuple and PythonCallable classes to PythonDataObjects. Additionally, unit tests are provided that exercise this functionality, including invoking manipulating and checking for validity of tuples, and invoking and checking for validity of callables using a variety of different syntaxes. The goal here is to eventually replace the code in python-wrapper.swig that directly uses the Python C API to deal with callables and name resolution with this code that can be more easily tested and debugged. llvm-svn: 252787
* Add a `PythonModule` class, and a root-level method for resolving names.Zachary Turner2015-11-112-12/+136
| | | | llvm-svn: 252765
* Fix Clang-tidy modernize-use-override warnings in some files in ↵Eugene Zelenko2015-10-242-58/+78
| | | | | | source/Plugins; other minor fixes. llvm-svn: 251167
* [SBValue] Add a method GetNumChildren(uint32_t max)Siva Chandra2015-10-212-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Along with this, support for an optional argument to the "num_children" method of a Python synthetic child provider has also been added. These have been added with the following use case in mind: Synthetic child providers currently have a method "has_children" and "num_children". While the former is good enough to know if there are children, it does not give any insight into how many children there are. Though the latter serves this purpose, calculating the number for children of a data structure could be an O(N) operation if the data structure has N children. The new method added in this change provide a middle ground. One can call GetNumChildren(K) to know if a child exists at an index K which can be as large as the callers tolerance can be. If the caller wants to know about children beyond K, it can make an other call with 2K. If the synthetic child provider maintains state about it counting till K previosly, then the next call is only an O(K) operation. Infact, all calls made progressively with steps of K will be O(K) operations. Reviewers: vharron, clayborg, granata.enrico Subscribers: labath, lldb-commits Differential Revision: http://reviews.llvm.org/D13778 llvm-svn: 250930
* Fix potential file i/o problem with python handles.Zachary Turner2015-10-204-37/+50
| | | | llvm-svn: 250838
* Fix linkage of `init_lldb` SWIG method in Python 3.Zachary Turner2015-10-161-1/+5
| | | | llvm-svn: 250531
* Convert SWIG typemap string operations to PythonObjects.Zachary Turner2015-10-162-5/+44
| | | | llvm-svn: 250530
* Update SWIG typemaps to use `PythonFile`.Zachary Turner2015-10-162-1/+26
| | | | | | | | Using the Python native C API is non-portable across Python versions, so this patch changes them to use the `PythonFile` class which hides the version specific differences behind a single interface. llvm-svn: 250525
* Introduce a `PythonFile` object, and use it everywhere.Zachary Turner2015-10-154-34/+133
| | | | | | | | | | | | | | | | | | | | | | | Python file handling got an overhaul in Python 3, and it affects the way we have to interact with files. Notably: 1) `PyFile_FromFile` no longer exists, and instead we have to use `PyFile_FromFd`. This means having a way to get an fd from a FILE*. For this we reuse the lldb_private::File class to convert between FILE*s and fds, since there are some subtleties regarding ownership rules when FILE*s and fds refer to the same file. 2) PyFile is no longer a builtin type, so there is no such thing as `PyFile_Check`. Instead, files in Python 3 are just instances of `io.IOBase`. So the logic for checking if something is a file in Python 3 is to check if it is a subclass of that module. Additionally, some unit tests are added to verify that `PythonFile` works as expected on Python 2 and Python 3, and `ScriptInterpreterPython` is updated to use `PythonFile` instead of manual calls to the various `PyFile_XXX` methods. llvm-svn: 250444
* Make uses of /dev/null portable across OSes.Zachary Turner2015-10-141-2/+3
| | | | | | | | | Most platforms have "/dev/null". Windows has "nul". Instead of hardcoding the string /dev/null at various places, make a constant that contains the correct value depending on the platform, and use that everywhere instead. llvm-svn: 250331
* Get Python unit tests working with Python 3.Zachary Turner2015-10-141-39/+28
| | | | | | | | | | | | | | | | | | | | | There were a couple of issues related to string handling that needed to be fixed. In particular, we cannot get away with converting `PyUnicode` objects to `PyBytes` objects and storing the `PyBytes` regardless of Python version. Instead we have to store a `PyUnicode` on Python 3 and a `PyString` on Python 2. The reason for this is that if you call `PyObject_Str` on a `PyBytes` in Python 3, it will return you a string that actually contains the string value wrappedin the characters b''. So if we create a `PythonString` with the value "test", and we call Str() on it, we will get back the string "b'test'", which breaks string equality. The only way to fix this is to store a native `PyUnicode` object under Python 3. With this CL, ScriptInterpreterPythonTests unit tests pass 100% under Python 2 and Python 3. llvm-svn: 250327
* Avoid a -Wreorder warning in ScriptInterpreterPython.cpp.Stephane Sezer2015-10-141-2/+2
| | | | llvm-svn: 250322
* Fix Python initialization for Python 3.Zachary Turner2015-10-141-46/+91
| | | | | | | | | | | | | Python 3 reverses the order in which you must call Py_InitializeEx and PyEval_InitThreads. Since that log is in itself already a little nuanced, it is refactored into a function so that the reversal is more clear. At the same time, there's a lot of logic during Python initialization to save off a bunch of state and then restore it after initialization is complete. To express this more cleanly, it is refactored to an RAII-style pattern where state is saved off on acquisition and restored on release. llvm-svn: 250306
* Minor cleanup on PythonDataObject constructors.Zachary Turner2015-10-142-5/+13
| | | | | | | | Added a constructor that takes list_size for `PythonList`. Made all single-argument constructors explicit. Re-ordered constructors to be consistent with other classes. llvm-svn: 250304
* Change swig interface files to use PythonDataObjects.Zachary Turner2015-10-142-4/+13
| | | | llvm-svn: 250303
* Fix compiler warnings in ScriptInterpreterPythonPavel Labath2015-10-141-1/+1
| | | | llvm-svn: 250282
* Change PyFile_FromFile to use PyFile_FromFd when using Py3.Zachary Turner2015-10-131-5/+17
| | | | llvm-svn: 250213
* Fix ref counting of Python objects.Zachary Turner2015-10-134-770/+659
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PythonObjects were being incorrectly ref-counted. This problem was pervasive throughout the codebase, leading to an unknown number of memory leaks and potentially use-after-free. The issue stems from the fact that Python native methods can either return "borrowed" references or "owned" references. For the former category, you *must* incref it prior to decrefing it. And for the latter category, you should not incref it before decrefing it. This is mostly an issue when a Python C API method returns a `PyObject` to you, but it can also happen with a method accepts a `PyObject`. Notably, this happens in `PyList_SetItem`, which is documented to "steal" the reference that you give it. So if you pass something to `PyList_SetItem`, you cannot hold onto it unless you incref it first. But since this is one of only two exceptions in the entire API, it's confusing and difficult to remember. Our `PythonObject` class was indiscriminantely increfing every object it received, which means that if you passed it an owned reference, you now have a dangling reference since owned references should not be increfed. We were doing this in quite a few places. There was also a fair amount of manual increfing and decrefing prevalent throughout the codebase, which is easy to get wrong. This patch solves the problem by making any construction of a `PythonObject` from a `PyObject` take a flag which indicates whether it is an owned reference or a borrowed reference. There is no way to construct a `PythonObject` without this flag, and it does not offer a default value, forcing the user to make an explicit decision every time. All manual uses of `PyObject` have been cleaned up throughout the codebase and replaced with `PythonObject` in order to make RAII the predominant pattern when dealing with native Python objects. Differential Revision: http://reviews.llvm.org/D13617 Reviewed By: Greg Clayton llvm-svn: 250195
* Fix build broken by r249885Zachary Turner2015-10-092-3/+3
| | | | llvm-svn: 249900
* Port native Python-API to 3.xZachary Turner2015-10-093-99/+227
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this change, liblldb is 95% of the way towards being able to work under both Python 2.x and Python 3.x. This should introduce no functional change for Python 2.x, but for Python 3.x there are some important changes. Primarily, these are: 1) PyString doesn't exist in Python 3. Everything is a PyUnicode. To account for this, PythonString now stores a PyBytes instead of a PyString. In Python 2, this is equivalent to a PyUnicode, and in Python 3, we do a conversion from PyUnicode to PyBytes and store the PyBytes. 2) PyInt doesn't exist in Python 3. Everything is a PyLong. To account for this, PythonInteger stores a PyLong instead of a PyInt. In Python 2.x, this requires doing a conversion to PyLong when creating a PythonInteger from a PyInt. In 3.x, there is no PyInt anyway, so we can assume everything is a PyLong. 3) PyFile_FromFile doesn't exist in Python 3. Instead there is a PyFile_FromFd. This is not addressed in this patch because it will require quite a large change to plumb fd's all the way through the system into the ScriptInterpreter. This is the only remaining piece of the puzzle to get LLDB supporting Python 3.x. Being able to run the test suite is not addressed in this patch. After the extension module can compile and you can enter an embedded 3.x interpreter, the test suite will be addressed in a followup. llvm-svn: 249886
* Fix Clang-tidy misc-use-override warnings in some files in ↵Pavel Labath2015-08-181-4/+4
| | | | | | | | | | include/lldb/Core, unify closing inclusion guards patch by Eugene Zelenko Differential Revision: http://reviews.llvm.org/D11695 llvm-svn: 245275
* First step in getting LLDB ready to support multiple different type systems.Greg Clayton2015-08-111-2/+2
| | | | | | | | This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system. All tests pass on MacOSX and passed on linux the last time this was submitted. llvm-svn: 244679
* Bug 24332 - Fix the build of lldb under GNU/Linux when using autotoolsSylvestre Ledru2015-08-051-0/+14
| | | | | | | | | | Reviewers: loladiro, jingham, emaste, zturner, brucem Subscribers: tberghammer, danalbert, srhines, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D11717 llvm-svn: 244039
* Convert the ScriptInterpreter system to a plugin-based one.Zachary Turner2015-07-306-0/+4681
Previously embedded interpreters were handled as ad-hoc source files compiled into source/Interpreter. This made it hard to disable a specific interpreter, or to add support for other interpreters and allow the developer to choose which interpreter(s) were enabled for a particular build. This patch converts script interpreters over to a plugin-based system. Script interpreters now live in source/Plugins/ScriptInterpreter, and the canonical LLDB interpreter, ScriptInterpreterPython, is moved there as well. Any new code interfacing with the Python C API must live in this location from here on out. Additionally, generic code should never need to reference or make assumptions about the presence of a specific interpreter going forward. Differential Revision: http://reviews.llvm.org/D11431 Reviewed By: Greg Clayton llvm-svn: 243681
OpenPOWER on IntegriCloud