summaryrefslogtreecommitdiffstats
path: root/lldb/scripts/Python
Commit message (Collapse)AuthorAgeFilesLines
* "Fix" TestFileHandle.py on non-darwin platformsPavel Labath2019-10-031-0/+8
| | | | | | | | | | | | | | | | | | This test exposed a very long standing issue that the python file objects returned by the FILE* typemap were unusable on non-darwin platforms. The reason they work on darwin is that they rely on a non-standard extension to fetch the "mode" of a FILE* object. On other platforms, this code was #ifdefed out, and so we were returning an empty mode. As there's no portable way to get this information, I just change the non-darwin path to return "r+", which should permit both reading and writing operations on the object. If the underlying file descriptor turns out to be incompatible with this mode, the operating system should return EBADF (or equivalent), instead of the "file not open for XXX" error from python. llvm-svn: 373573
* factor out an abstract base class for FileLawrence D'Anna2019-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch factors out File as an abstract base class and moves most of its actual functionality into a subclass called NativeFile. In the next patch, I'm going to be adding subclasses of File that don't necessarily have any connection to actual OS files, so they will not inherit from NativeFile. This patch was split out as a prerequisite for https://reviews.llvm.org/D68188 Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68317 llvm-svn: 373564
* new api class: SBFileLawrence D'Anna2019-10-031-1/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* File::Clear() -> File::TakeStreamAndClear()Lawrence D'Anna2019-10-011-3/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: File::Clear() is an ugly function. It's only used in one place, which is the swig typemaps for FILE*. This patch refactors and renames that function to make it clear what it's really for and why nobody else should use it. Both File::TakeStreamAndClear() and the FILE* typemaps will be removed in later patches after a suitable replacement is in place. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68160 llvm-svn: 373285
* Give an error when StepUsingScriptedThreadPlan is passed a bad classname.Jim Ingham2019-09-281-1/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D68173 llvm-svn: 373135
* Convert FileSystem::Open() to return Expected<FileUP>Lawrence D'Anna2019-09-261-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [lldb] Move swig call from python code to cmakeHaibo Huang2019-09-251-396/+0
| | | | | | | | | | | | | | Summary: Elimiates lots of unused code. Reviewers: labath, mgorny Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68007 llvm-svn: 372895
* prepare_binding_Python: print readable errors if SWIG failsJonas Devlieghere2019-09-201-4/+6
| | | | | | | | | | | | When swig fails, all the errors are squished onto one line with \n quoting. It's very hard to read. This will print them out in a more reasonable format. Patch by: Lawrence D'Anna Differential revision: https://reviews.llvm.org/D67790 llvm-svn: 372442
* [Python] Implement __next__ for value_iterJonas Devlieghere2019-09-041-1/+4
| | | | | | | | | Python 3 iteration calls the next() method instead of next() and value_iter only implemented the Python 2 version. Differential revision: https://reviews.llvm.org/D67184 llvm-svn: 370954
* [Python] Implement truth testing for lldb.valueJonas Devlieghere2019-09-041-0/+3
| | | | | | | | | Python 3 calls __bool__() instead of __len__() and lldb.value only implemented the __len__ method. This adds the __bool__() implementation. Differential revision: https://reviews.llvm.org/D67183 llvm-svn: 370953
* [Python] Fix whitespace before making changes (NFC)Jonas Devlieghere2019-09-041-164/+164
| | | | llvm-svn: 370952
* [lldb] Remove Xcode project legacyStefan Granitz2019-07-241-309/+0
| | | | | | | | | | | | | | Summary: Since D65109 removed the manually maintained Xcode project, there's a few things we don't need anymore. Anything here we should keep or anything more to remove? Reviewers: JDevlieghere, jasonmolenda, clayborg, jingham, lanza, teemperor Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D65155 llvm-svn: 366879
* [lldb][swig] Fix autodocs flag parsingJordan Rupprecht2019-07-181-1/+1
| | | | | | | | r366471 added "-features autodoc" without a trailing comment, leading to `Unrecognized option -features autodoc-threads` due to implicit string concatenation. Add a comma to fix that. Also separate into "-features" and "autodoc", otherwise it gets parsed as a single "-features autodoc" flag which is also not recognized (it must be two separate CLI args). llvm-svn: 366478
* [swig] Enable autodoc featureJonas Devlieghere2019-07-181-0/+1
| | | | | | | | | This patch enables the SWIG `autodoc` feature so that the generated Python reference [1] includes class properties. [1] https://lldb.llvm.org/python_reference/index.html llvm-svn: 366471
* Kill modify-python-lldb.pyPavel Labath2019-04-242-188/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: After the last round of cleanups, this script was almost a no-op. The only piece of functionality that remained was the one which tried to make the swig-generated function signatures more pythonic. The "tried" part is important here, as it wasn't doing a really good job and the end result was not valid python nor c (e.g., SetExecutable(SBAttachInfo self, str const * path)). Doing these transformations another way is not possible, as these signatures are generated by swig, and not present in source. However, given that this is the only reason why we need a swig post-process step, and that the current implementation is pretty sub-optimal, this patch simply abandons the signature fixup idea, and chooses to simplify our build process instead. Reviewers: amccarth, jingham, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D61000 llvm-svn: 359092
* modify-python-lldb: Remove \a-removing codePavel Labath2019-04-231-4/+0
| | | | | | instead, remove \a directly from the interface files. llvm-svn: 358967
* modify-python-lldb.py: Remove docstring formatting codePavel Labath2019-04-211-15/+1
| | | | | | | | | | | The strings have been already cleaned up in r358683, so this code is not doing anything anymore. While comparing the outputs before and after removing the formatting code, I've found a couple of docstrings that managed to escape my perl script in r358683, so I format them manually with this patch. llvm-svn: 358846
* [Shell] Simplify Extracting Python VersionJonas Devlieghere2019-04-181-2/+1
| | | | | | | Instead of parsing the Python version with a fairly convoluted regex, just print the major and minor version and call it a day. llvm-svn: 358635
* modify-python-lldb.py: Remove ifdef SWIG-removing codePavel Labath2019-04-081-13/+4
| | | | | | | | | There are no patterns like that in the generated swig files (there probably were some back in the days when we were running swig over the header files directly), so this is dead code and has no effect on the generated file. llvm-svn: 357890
* modify-python-lldb.py: Insert initialization code with swig insteadPavel Labath2019-04-051-7/+0
| | | | | | | | This is the last functional change to the generated python module being done by modify-python-lldb.py. The remaining code just deals with reformatting of comments. llvm-svn: 357755
* modify-python-lldb.py: (Re)move __len__ and __iter__ supportPavel Labath2019-04-041-100/+3
| | | | | | | | | | | | | | | | Summary: This patch moves the modify-python-lldb code for adding new functions to the SBModule class into the SBModule interface file. As this is the last class using this functionality, I also remove all support for this kind of modifications from modify-python-lldb.py. Reviewers: amccarth, clayborg, jingham Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D60195 llvm-svn: 357680
* modify-python-lldb.py: clean up __iter__ and __len__ supportPavel Labath2019-04-031-35/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of modifying the swig-generated code, just add the appropriate methods to the interface files in order to get the swig to do the generation for us. This is a straight-forward move from the python script to the interface files. The single class which has nontrivial handling in the script (SBModule) has been left for a separate patch. For the cases where I did not find any tests exercising the iteration/length methods (i.e., no tests failed after I stopped emitting them), I tried to add basic tests for that functionality. Reviewers: zturner, jingham, amccarth Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D60119 llvm-svn: 357572
* Make operator==s consistent between c++ and python APIsPavel Labath2019-04-021-43/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: modify-python-lldb.py had code to insert python equality operators to some classes. Some of those classes already had c++ equality operators, and some didn't. This makes the situation more consistent, by removing all equality handilng from modify-python-lldb. Instead, I add c++ operators to classes where they were missing, and expose them in the swig interface files so that they are available to python too. The only tricky case was the SBAddress class, which had an operator== defined as a free function, which is not handled by swig. This function cannot be removed without breaking ABI, and we cannot add an extra operator== member, as that would make equality comparisons ambiguous. For this class, I define a python __eq__ function by hand and have it delegate to the operator!=, which I have defined as a member function. This isn't fully NFC, as the semantics of some equality functions in python changes slightly, but I believe it changes for the better (e.g., previously SBBreakpoint.__eq__ would consider two breakpoints with the same ID as equal, even if they belonged to different targets; now they are only equal if they belong to the same target). Reviewers: jingham, clayborg, zturner Subscribers: jdoerfert, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D59819 llvm-svn: 357463
* [Python] Remove readline moduleJonas Devlieghere2019-03-293-125/+0
| | | | | | | | | | | Todd added this empty readline module to workaround an issue with an old version of Python on Ubuntu in 2014 (18841). In the meantime, libedit seems to have fixed the underlying issue, and indeed, I wasn't able to reproduce this. Differential revision: https://reviews.llvm.org/D59972 llvm-svn: 357277
* Fix the swig typemap for "uint32_t *versions, uint32_t num_versions".Jim Ingham2019-03-281-10/+5
| | | | | | | | | It was making a list of a certain size but not always filling in that many elements, which would lead to a crash iterating over the list. Differential Revision: https://reviews.llvm.org/D59913 llvm-svn: 357207
* Python 2/3 compatibility: from __future__ import print_functionSerge Guelton2019-03-211-11/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D59580 llvm-svn: 356695
* Fix/unify SBType comparisonPavel Labath2019-03-131-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In my next step at cleaning up modify-python-lldb.py, I started focusing on equality comparison. To my surprise, I found out that both python and c++ versions of the SBType class implement equality comparison, but each one does it differently. While the python version was implemented in terms of type name equality, the C++ one used a deep comparison on the underlying objects. Removing the python version caused one test to fail (TestTypeList). This happened because the c++ version of operator== boiled down to TypePair::operator==, which contains two items: the compiler_type and type_sp. In this case, the compiler_type was identical, but one of the objects had the type_sp field unset. I tried fixing the code so that both objects keep their type_sp member, but it wasn't easy, because there are so many operations which just work with the CompilerType types, and so any operation on the SBType (the test in question was doing GetPointeeType on the type of one variable and expecting it to match the type of another variable), cause that second member to be lost. So instead, here I relax the equality comparison on the TypePair class. Now, this class ignores the type_sp for the purposes of comparison, and uses the CompilerType only. This seems reasonable, as each TypeSP is able to convert itself to a CompilerType. Reviewers: clayborg, aprantl, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D59217 llvm-svn: 356048
* Add "operator bool" to SB APIsPavel Labath2019-03-111-15/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: Our python version of the SB API has (the python equivalent of) operator bool, but the C++ version doesn't. This is because our python operators are added by modify-python-lldb.py, which performs postprocessing on the swig-generated interface files. In this patch, I add the "operator bool" to all SB classes which have an IsValid method (which is the same logic used by modify-python-lldb.py). This way, we make the two interfaces more constent, and it allows us to rely on swig's automatic syntesis of python __nonzero__ methods instead of doing manual fixups. Reviewers: zturner, jingham, clayborg, jfb, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58792 llvm-svn: 355824
* Insert blocks of python code with swig instead of modify-python-lldb.pyPavel Labath2019-02-271-125/+0
| | | | | | | | | | | | | | | | | | | Summary: Swig is perfectly capable of inserting blocks of python code into its output (and we use those fascilities already), so there's no need for this to be done in a post-process step. lldb_iter is a general-purpose utility used from many classes, so I add it to the main swig file. The other two blocks are tied to a specific class, so I add it to the interface file of that class. Reviewers: zturner, jingham, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58350 llvm-svn: 354975
* Embed swig version into lldb.py in a different wayPavel Labath2019-02-151-22/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of doing string chopping on the resulting python file, get swig to output the version for us. The two things which make slightly non-trivial are: - in order to get swig to expand SWIG_VERSION for us, we cannot use %pythoncode directly, but we have to go through an intermediate macro. - SWIG_VERSION is a hex number, but it's components are supposed to be interpreted decimally, so there is a bit of integer magic needed to get the right number to come out. I've tested that this approach works both with the latest (3.0.12) and oldest (1.3.40) supported swig. Reviewers: zturner, jingham, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58172 llvm-svn: 354104
* 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
* [Python] Update PyString_FromString() to work for python 2 and 3.Davide Italiano2019-01-092-10/+3
| | | | | | | | | | Reviewers: aprantl, JDevlieghere, friss, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D56511 llvm-svn: 350769
* [lldb] Introduce StackFrameRecognizer [take 3]Kuba Mracek2018-10-311-0/+46
| | | | | | | | This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector). Differential Revision: https://reviews.llvm.org/D44603 llvm-svn: 345693
* Revert r345686 due to build failuresKuba Mracek2018-10-311-46/+0
| | | | llvm-svn: 345688
* [lldb] Introduce StackFrameRecognizer [take 2]Kuba Mracek2018-10-311-0/+46
| | | | | | | | This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector). Differential Revision: https://reviews.llvm.org/D44603 llvm-svn: 345686
* Revert r345678 (build failure on Linux machines).Kuba Mracek2018-10-311-46/+0
| | | | llvm-svn: 345680
* [lldb] Introduce StackFrameRecognizerKuba Mracek2018-10-311-0/+46
| | | | | | | | This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector). Differential Revision: https://reviews.llvm.org/D44603 llvm-svn: 345678
* [Swig] Merge typemaps with same bodiesTatyana Krasnukha2018-09-251-196/+53
| | | | | | Differential Revision: https://reviews.llvm.org/D52376 llvm-svn: 342959
* Add a "scripted" breakpoint type to lldb.Jim Ingham2018-09-132-0/+109
| | | | | | | | | | This change allows you to write a new breakpoint type where the logic for setting breakpoints is determined by a Python callback written using the SB API's. Differential Revision: https://reviews.llvm.org/D51830 llvm-svn: 342185
* Remove undefined behavior around the use of StateTypeShafik Yaghmour2018-09-111-0/+20
| | | | | | | | | | rdar://problem/43530233 Patch by Shafik Yaghmour. Differential Revision: https://reviews.llvm.org/D51445 llvm-svn: 341957
* Hold GIL while allocating memory for PythonString.Tatyana Krasnukha2018-09-051-0/+82
| | | | | | | | | | | | | | Summary: Swig wraps C++ code into SWIG_PYTHON_THREAD_BEGIN_ALLOW; ... SWIG_PYTHON_THREAD_END_ALLOW; Thus, LLDB crashes with "Fatal Python error: Python memory allocator called without holding the GIL" when calls an lldb_SB***___str__ function. Reviewers: clayborg Reviewed By: clayborg Differential Revision: https://reviews.llvm.org/D51569 llvm-svn: 341482
* Fix and simplify lldb.command decoratorDave Lee2018-07-041-19/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change fixes one issue with `lldb.command`, and also reduces the implementation. The fix: a command function's docstring was not shown when running `help <command_name>`. This is because the docstring attached the source function is not propagated to the decorated function (`f.__call__`). By returning the original function, the docstring will be properly displayed by `help`. Also with this change, the command name is assumed to be the function's name, but can still be explicitly defined as previously. Additionally, the implementation was updated to: * Remove inner class * Remove use of `inspect` module * Remove `*args` and `**kwargs` Reviewers: clayborg Reviewed By: clayborg Subscribers: keith, xiaobai, lldb-commits Differential Revision: https://reviews.llvm.org/D48658 llvm-svn: 336287
* Python: adjust the include directoriesSaleem Abdulrasool2018-06-041-6/+5
| | | | | | | Restructure the include search order to adjust for libedit. This ensures that the variables are not unused if they are not defined. llvm-svn: 333863
* build: use cmake to find the libedit contentSaleem Abdulrasool2018-05-221-1/+4
| | | | | | | | Use proper cmake techniques to detect where the libedit package resides. This allows for the use of libedit from an alternative location which is needed for supporting cross-compilation. llvm-svn: 333041
* Change SBProcess::ReadCStringFromMemory() back to returningJason Molenda2017-12-221-1/+2
| | | | | | | | | an empty Python string object when it reads a 0-length string out of memory (and a successful SBError object). <rdar://problem/26186692> llvm-svn: 321338
* Make breakpoint names real entities.Jim Ingham2017-09-142-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When introduced, breakpoint names were just tags that you could apply to breakpoints that would allow you to refer to a breakpoint when you couldn't capture the ID, or to refer to a collection of breakpoints. This change makes the names independent holders of breakpoint options that you can then apply to breakpoints when you add the name to the breakpoint. It adds the "breakpoint name configure" command to set up or reconfigure breakpoint names. There is also full support for then in the SB API, including a new SBBreakpointName class. The connection between the name and the breakpoints sharing the name remains live, so if you reconfigure the name, all the breakpoint options all change as well. This allows a quick way to share complex breakpoint behavior among a bunch of breakpoints, and a convenient way to iterate on the set. You can also create a name from a breakpoint, allowing a quick way to copy options from one breakpoint to another. I also added the ability to make hidden and delete/disable protected names. When applied to a breakpoint, you will only be able to list, delete or disable that breakpoint if you refer to it explicitly by ID. This feature will allow GUI's that need to use breakpoints for their own purposes to keep their breakpoints from getting accidentally disabled or deleted. <rdar://problem/22094452> llvm-svn: 313292
* Fix a python object leak in SWIG glue.Zachary Turner2017-06-211-1/+2
| | | | | | | | | | PyObject_CallFunction returns a PyObject which needs to be decref'ed when it is no longer needed. Patch by David Luyer Differential Revision: https://reviews.llvm.org/D33740 llvm-svn: 305873
* Install six.py conditionallyKamil Rytarowski2017-02-041-1/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: The current version of LLDB installs six.py into global python library directory. This approach produces conflicts downstream with distribution's py-six copy. Introduce new configure option LLDB_USE_SYSTEM_SIX (disabled by default). Once specified as TRUE, six.py won't be installed to Python's directory. Add new option in finishSwigWrapperClasses.py, namely --useSystemSix. Sponsored by <The NetBSD Foundation> Reviewers: mgorny, emaste, clayborg, joerg, labath Reviewed By: labath Subscribers: #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D29405 llvm-svn: 294071
* Fix the cmake declaration syntaxSylvestre Ledru2016-12-171-1/+1
| | | | llvm-svn: 290045
* Support of lldb on Kfreebsd Sylvestre Ledru2016-12-171-1/+1
| | | | | | | | | | | | | | Summary: Patch by Pino Toscano. Reported in http://bugs.debian.org/835665 Reviewers: tfiala, emaste Subscribers: beanz, mgorny, emaste, krytarowski, brucem, tberghammer, danalbert, srhines, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D23977 llvm-svn: 290044
OpenPOWER on IntegriCloud