summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
Commit message (Collapse)AuthorAgeFilesLines
* eliminate nontrivial Reset(...) from TypedPythonObjectLawrence D'Anna2019-10-191-11/+46
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This deletes `Reset(...)`, except for the no-argument form `Reset()` from `TypedPythonObject`, and therefore from `PythonString`, `PythonList`, etc. It updates the various callers to use assignment, `As<>`, `Take<>`, and `Retain<>`, as appropriate. followon to https://reviews.llvm.org/D69080 Reviewers: JDevlieghere, clayborg, labath, jingham Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D69133 llvm-svn: 375350
* [LLDB] bugfix: command script add -f doesn't work for some callablesLawrence D'Anna2019-10-191-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When users define a debugger command from python, they provide a callable object. Because the signature of the function has been extended, LLDB needs to inspect the number of parameters the callable can take. The rule it was using to decide was weird, apparently not tested, and giving wrong results for some kinds of python callables. This patch replaces the weird rule with a simple one: if the callable can take 5 arguments, it gets the 5 argument version of the signature. Otherwise it gets the old 4 argument version. It also adds tests with a bunch of different kinds of python callables with both 4 and 5 arguments. Reviewers: JDevlieghere, clayborg, labath, jingham Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D69014 llvm-svn: 375333
* eliminate one form of PythonObject::Reset()Lawrence D'Anna2019-10-171-26/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: I'd like to eliminate all forms of Reset() and all public constructors on these objects, so the only way to make them is with Take<> and Retain<> and the only way to copy or move them is with actual c++ copy, move, or assignment. This is a simple place to start. Reviewers: JDevlieghere, clayborg, labath, jingham Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D69080 llvm-svn: 375182
* clean up the implementation of PythonCallable::GetNumArgumentsLawrence D'Anna2019-10-171-15/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current implementation of PythonCallable::GetNumArguments is not exception safe, has weird semantics, and is just plain incorrect for some kinds of functions. Python 3.3 introduces inspect.signature, which lets us easily query for function signatures in a sane and documented way. This patch leaves the old implementation in place for < 3.3, but uses inspect.signature for modern pythons. It also leaves the old weird semantics in place, but with FIXMEs grousing about it. We should update the callers and fix the semantics in a subsequent patch. It also adds some tests. Reviewers: JDevlieghere, clayborg, labath, jingham Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68995 llvm-svn: 375181
* delete SWIG typemaps for FILE*Lawrence D'Anna2019-10-171-14/+0
| | | | | | | | | | | | | | | | | | Summary: The SWIG typemaps for FILE* are no longer used, so this patch deletes them. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68963 llvm-svn: 375073
* eliminate virtual methods from PythonDataObjectsLawrence D'Anna2019-10-151-118/+84
| | | | | | | | | | | | | | | | | | | | | Summary: This patch eliminates a bunch of boilerplate from PythonDataObjects, as well as the use of virtual methods. In my opinion it also makes the Reset logic a lot more clear and easy to follow. The price is yet another template. I think it's worth it. Reviewers: JDevlieghere, jasonmolenda, labath, zturner Reviewed By: JDevlieghere, labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68918 llvm-svn: 374916
* SBFile::GetFile: convert SBFile back into python native files.Lawrence D'Anna2019-10-151-3/+16
| | | | | | | | | | | | | | | | | | | | | | Summary: This makes SBFile::GetFile public and adds a SWIG typemap to convert the result back into a python native file. If the underlying File itself came from a python file, it is returned identically. Otherwise a new python file object is created using the file descriptor. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68737 llvm-svn: 374911
* exception handling in PythonDataObjects.Lawrence D'Anna2019-10-081-11/+262
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Python APIs nearly all can return an exception. They do this by returning NULL, or -1, or some such value and setting the exception state with PyErr_Set*(). Exceptions must be handled before further python API functions are called. Failure to do so will result in asserts on debug builds of python. It will also sometimes, but not usually result in crashes of release builds. Nearly everything in PythonDataObjects.h needs to be updated to account for this. This patch doesn't fix everything, but it does introduce some new methods using Expected<> return types that are safe to use. split off from https://reviews.llvm.org/D68188 Reviewers: JDevlieghere, jasonmolenda, labath, zturner Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68547 llvm-svn: 374094
* Pass an SBStructuredData to scripted ThreadPlans on use.Jim Ingham2019-10-031-0/+4
| | | | | | | | | | This will allow us to write reusable scripted ThreadPlans, since you can use key/value pairs with known keys in the plan to parametrize its behavior. Differential Revision: https://reviews.llvm.org/D68366 llvm-svn: 373675
* new api class: SBFileLawrence D'Anna2019-10-031-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: SBFile is a scripting API wrapper for lldb_private::File This is the first step in a project to enable arbitrary python io.IOBase file objects -- including those that override the read() and write() methods -- to be used as the main debugger IOStreams. Currently this is impossible because python file objects must first be converted into FILE* streams by SWIG in order to be passed into the debugger. full prototype: https://github.com/smoofra/llvm-project/tree/files Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath Reviewed By: labath Subscribers: labath, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67793 llvm-svn: 373562
* [JSON] Use LLVM's library for encoding JSON in StructuredDataJonas Devlieghere2019-10-011-1/+1
| | | | | | | | | This patch replaces the hand-rolled JSON emission in StructuredData with LLVM's JSON library. Differential revision: https://reviews.llvm.org/D68248 llvm-svn: 373359
* Convert FileSystem::Open() to return Expected<FileUP>Lawrence D'Anna2019-09-261-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
* Delete unnecessary copy ctorsFangrui Song2019-05-221-9/+0
| | | | llvm-svn: 361358
* [Python] Remove unused includesJonas Devlieghere2019-03-271-5/+0
| | | | llvm-svn: 357126
* Add PythonBoolean type to the PythonDataObjectsTatyana Krasnukha2019-02-161-0/+24
| | | | | | Differential Revision: https://reviews.llvm.org/D57817 llvm-svn: 354206
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Remove header grouping comments.Jonas Devlieghere2018-11-111-4/+0
| | | | | | | | This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. llvm-svn: 346626
* Partially revert r335236Pavel Labath2018-06-211-0/+4
| | | | | | | | | | Jim pointed out that XCode has build configurations that build without python and removing the ifdefs around the python code breaks them. This reverts the #ifdef part of the above patch, while keeping the cmake parts. llvm-svn: 335260
* ScriptInterpreterPython cleanupPavel Labath2018-06-211-4/+0
| | | | | | | | | Instead of #ifdef-ing the contents of all files in the plugin for all non-python builds, just disable the plugin at the cmake level. Also, remove spurious extra linking of the Python plugin in liblldb. This plugin is already included as a part of LLDB_ALL_PLUGINS variable. llvm-svn: 335236
* Revert r317182 for https://reviews.llvm.org/D39128Jason Molenda2017-11-021-2/+0
| | | | | | | we're still failing on android. I'll ask Larry to ask Pavel for any tips he might be able to give. llvm-svn: 317183
* Commit Lawrence D'Anna's patch to changeJason Molenda2017-11-021-0/+2
| | | | | | | | | | | | | | | SetOututFileHandle to work with IOBase. I did make one change after checking with Larry -- I renamed SBDebugger::Flush to FlushDebuggerOutputHandles and added a short docstring to the .i file to make it a little clearer under which context programs may need to use this API. Differential Revision: https://reviews.llvm.org/D39128 <rdar://problem/34870417> llvm-svn: 317182
* Move StructuredData from Core to UtilityPavel Labath2017-06-271-1/+1
| | | | | | | | | | | | | | | | Summary: It had a dependency on StringConvert and file reading code, which is not in Utility. I've replaced that code by equivalent llvm operations. I've added a unit test to demonstrate that parsing a file still works. Reviewers: zturner, jingham Subscribers: kubamracek, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D34625 llvm-svn: 306394
* Remove dependencies from Utility to Core and Target.Zachary Turner2017-02-141-1/+2
| | | | | | | | | | With this patch, the only dependency left is from Utility to Host. After this is broken, Utility will finally be standalone. Differential Revision: https://reviews.llvm.org/D29909 llvm-svn: 295088
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-408/+306
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Moved #include for lldb-python.h to a distinct group with a reminder commentKate Stone2016-08-191-1/+3
| | | | | | | declaring that it must be first. Failure to do so results in build failures on macOS due to subtle header conflicts. llvm-svn: 279315
* Make sure files include what they use (part 2/2)Pavel Labath2016-08-111-2/+3
| | | | | | This makes lldb still compile on linux after a project-wide clang-format llvm-svn: 278335
* 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-0/+1
| | | | | | | | | | | 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
* Fix swig typemap for SBEvent.Zachary Turner2016-01-251-0/+34
| | | | | | | | | | | 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/+2
| | | | | | | | output if an immediate output file was set in the result object via a Python file object Fixes rdar://24130303 llvm-svn: 257644
* Don't define Bytes and String to be the same number on Py2.Zachary Turner2016-01-111-4/+0
| | | | | | This is causing issues with case labels having the same value. llvm-svn: 257409
* Introduce a PythonBytes class into PythonDataObjects.Zachary Turner2016-01-111-0/+41
| | | | | | | This class behaves the same as PythonString on Python2, but differently on Python3. Unittests are added as well. llvm-svn: 257397
* Modernize FormatBacktrace() and make portable for Python 3.Zachary Turner2015-11-131-0/+3
| | | | llvm-svn: 253085
* Make PythonDataObjects.h work when LLDB_DISABLE_PYTHON=1Zachary Turner2015-11-131-0/+4
| | | | llvm-svn: 253054
* Fix non-Windows build after r252906.Zachary Turner2015-11-121-2/+2
| | | | llvm-svn: 252909
* Begin converting uses of PyCallable to PythonCallable.Zachary Turner2015-11-121-2/+32
| | | | | | | | | | | | | | | | 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-2/+71
| | | | | | | | | | | | | | 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-10/+39
| | | | llvm-svn: 252765
* Fix Clang-tidy modernize-use-override warnings in some files in ↵Eugene Zelenko2015-10-241-7/+15
| | | | | | source/Plugins; other minor fixes. llvm-svn: 251167
* Fix potential file i/o problem with python handles.Zachary Turner2015-10-201-0/+1
| | | | llvm-svn: 250838
* Convert SWIG typemap string operations to PythonObjects.Zachary Turner2015-10-161-0/+11
| | | | llvm-svn: 250530
* Update SWIG typemaps to use `PythonFile`.Zachary Turner2015-10-161-1/+4
| | | | | | | | 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-1/+21
| | | | | | | | | | | | | | | | | | | | | | | 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
* Minor cleanup on PythonDataObject constructors.Zachary Turner2015-10-141-5/+7
| | | | | | | | 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-141-3/+12
| | | | llvm-svn: 250303
* Fix ref counting of Python objects.Zachary Turner2015-10-131-172/+197
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-091-1/+1
| | | | llvm-svn: 249900
* Port native Python-API to 3.xZachary Turner2015-10-091-10/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+279
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