summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix a problem where if a uint64_t value is placed into a python dictionary ↵Greg Clayton2016-08-101-1/+12
| | | | | | | | and sent up to LLDB and converted to StructuredData, it would not be able to parse the full 64 bit value. A number like 0xf000000000000000L could be placed into a dictionary, and sent to LLDB and it would end up being 0xffffffffffffffff since it would overflow a int64_t. We leave the old code there, but if it overflows, we treat the number like a uint64_t and get it to decode correctly. Added a gtest to cover this so we don't regress. I verified the gtest failed prior to the fix, and it succeeds after it. <rdar://problem/27409265> llvm-svn: 278304
* Add a default-value bool flag pretty_print to the StructuredData Dump methods.Jason Molenda2016-07-201-1/+1
| | | | | | | | | They will dump pretty-print (indentation, extra whitepsace) by default. I'll make a change to ProcessGDBRemote soon so it stops sending JSON strings to debugserver pretty-printed; it's unnecessary extra bytes being sent between the two. llvm-svn: 276079
* Fix an issue where the @lldb.command marker would not work with the new ↵Enrico Granata2016-06-241-1/+25
| | | | | | | | | | | 5-argument version of the Python command function This: a) teaches PythonCallable to look inside a callable object b) teaches PythonCallable to discover whether a callable method is bound c) teaches lldb.command to dispatch to either the older 4 argument version or the newer 5 argument version llvm-svn: 273640
* Make File option flags consistent for Python APIStephane Sezer2016-03-241-2/+2
| | | | | | | | | | | | | | | | | | Summary: Fixes SBCommandReturnObject::SetImmediateOutputFile() and SBCommandReturnObject::SetImmediateOutputFile() for files opened with "a" or "a+" by resolving inconsistencies between File and our Python parsing of file objects. Reviewers: granata.enrico, Eugene.Zelenko, jingham, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18228 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 264351
* Unicode support on Win32.Zachary Turner2016-03-221-3/+4
| | | | | | | | | | | | | Win32 API calls that are Unicode aware require wide character strings, but LLDB uses UTF8 everywhere. This patch does conversions wherever necessary when passing strings into and out of Win32 API calls. Patch by Cameron Differential Revision: http://reviews.llvm.org/D17107 Reviewed By: zturner, amccarth llvm-svn: 264074
* Fix swig typemap for SBEvent.Zachary Turner2016-01-251-0/+85
| | | | | | | | | | | This needs to be able to handle bytes, strings, and bytearray objects. In Python 2 this was easy because bytes and strings are the same thing, but in Python 3 the 2 cases need to be handled separately. So as not to mix raw Python C API code with PythonDataObjects code, I've also introduced a PythonByteArray class to PythonDataObjects to make the paradigm used here consistent. llvm-svn: 258741
* Fix an issue where scripted commands would not actually print any of their ↵Enrico Granata2016-01-131-0/+20
| | | | | | | | output if an immediate output file was set in the result object via a Python file object Fixes rdar://24130303 llvm-svn: 257644
* Introduce a PythonBytes class into PythonDataObjects.Zachary Turner2016-01-111-0/+104
| | | | | | | This class behaves the same as PythonString on Python2, but differently on Python3. Unittests are added as well. llvm-svn: 257397
* Python3 - Fix some issues related to `PythonFile` class.Zachary Turner2015-11-161-0/+6
| | | | | | | | Python 3 has lots of new debug asserts, and some of these were firing on PythonFile. Specifically related to handling of invalid files. llvm-svn: 253261
* Modernize FormatBacktrace() and make portable for Python 3.Zachary Turner2015-11-131-0/+8
| | | | llvm-svn: 253085
* Fix non-Windows build after r252906.Zachary Turner2015-11-121-1/+1
| | | | llvm-svn: 252909
* Begin converting uses of PyCallable to PythonCallable.Zachary Turner2015-11-121-13/+17
| | | | | | | | | | | | | | | | 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-111-4/+251
| | | | | | | | | | | | | | 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-111-2/+97
| | | | llvm-svn: 252765
* Fix potential file i/o problem with python handles.Zachary Turner2015-10-201-0/+5
| | | | llvm-svn: 250838
* Convert SWIG typemap string operations to PythonObjects.Zachary Turner2015-10-161-5/+33
| | | | llvm-svn: 250530
* Update SWIG typemaps to use `PythonFile`.Zachary Turner2015-10-161-0/+22
| | | | | | | | 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-151-0/+85
| | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* Minor cleanup on PythonDataObject constructors.Zachary Turner2015-10-141-0/+6
| | | | | | | | 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
* Fix ref counting of Python objects.Zachary Turner2015-10-131-193/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Port native Python-API to 3.xZachary Turner2015-10-091-54/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Convert the ScriptInterpreter system to a plugin-based one.Zachary Turner2015-07-301-0/+522
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