summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
Commit message (Collapse)AuthorAgeFilesLines
* Add the ability to pass extra args to a Python breakpoint callback.Jim Ingham2019-10-251-0/+8
| | | | | | | | | | | | | | | | | For example, it is pretty easy to write a breakpoint command that implements "stop when my caller is Foo", and it is pretty easy to write a breakpoint command that implements "stop when my caller is Bar". But there's no way to write a generic "stop when my caller is..." function, and then specify the caller when you add the command to a breakpoint. With this patch, you can pass this data in a SBStructuredData dictionary. That will get stored in the PythonCommandBaton for the breakpoint, and passed to the implementation function (if it has the right signature) when the breakpoint is hit. Then in lldb, you can say: (lldb) break com add -F caller_is -k caller_name -v Foo More generally this will allow us to write reusable Python breakpoint commands. Differential Revision: https://reviews.llvm.org/D68671
* [lldb] Unifying lldb python pathHaibo Huang2019-10-071-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on mgorny@'s D67890 There are 3 places where python site-package path is calculated independently: 1. finishSwigPythonLLDB.py where files are written to site-packages. 2. lldb/scripts/CMakeLists.txt where site-packages are installed. 3. ScriptInterpreterPython.cpp where site-packages are added to PYTHONPATH. This change creates the path once and use it everywhere. So that they will not go out of sync. Also it provides a chance for cross compiling users to specify the right path for site-packages. Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68442 llvm-svn: 373991
* [ScriptInterpreter] Pass the debugger instead of the command interpreterJonas Devlieghere2019-04-261-2/+2
| | | | | | | | | | | | | | | | As discussed in D61090, there's no good reason for the script interpreter to depend on the command interpreter. When looking at the code, it becomes clear that we mostly use the command interpreter as a way to access the debugger. Hence, it makes more sense to just pass that to the script interpreter directly. This is part 1 out of 2. I have another patch in the pipeline that changes the ownership of the script interpreter to the debugger as well, but I didn't get around to finish that today. Differential revision: https://reviews.llvm.org/D61172 llvm-svn: 359330
* [Python] Remove Python include from ScriptInterpreterPython.hJonas Devlieghere2019-03-291-397/+7
| | | | | | | | | | | This patch limits the scope of the python header to the implementation of the python script interpreter plugin. ScriptInterpreterPython is now an abstract interface that doesn't expose any Python specific types, and is implemented by the ScriptInterpreterPythonImpl. Differential revision: https://reviews.llvm.org/D59976 llvm-svn: 357307
* [ScriptInterpreterPython] Remove unused field (NFC)Jonas Devlieghere2019-03-291-1/+0
| | | | | | The m_lldb_module was initialized but not used. llvm-svn: 357292
* [Python] Remove dynamic indirectionJonas Devlieghere2019-03-261-180/+0
| | | | | | | Now that the Python plugin relies on the SWIG symbols, we no longer need to dynamically resolve these functions. llvm-svn: 357034
* [ScriptInterpreterPython] Make SWIG callback private (NFC)Jonas Devlieghere2019-03-251-112/+146
| | | | | | | | With the initialization taking place inside the Python script interpreter, these function no longer need to be public. The exception is the g_swig_init_callback which is used from the RAII object. llvm-svn: 356944
* [ScriptInterpreterPython] Move SWIG initialization into the Python plugin (NFC)Jonas Devlieghere2019-03-251-36/+37
| | | | | | Abstract initialization of the Python SWIG support in the Python plugin. llvm-svn: 356942
* [ScriptInterpreterPython] Remove dead code.Davide Italiano2019-03-191-16/+0
| | | | llvm-svn: 356487
* Quiet command regex instructions during batch executionDave Lee2019-03-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Within .lldbinit, regex commands can be structured as a list of substitutions over multiple lines. It's possible that this is uninentional, but it works and has benefits. For example: command regex <command-name> s/pat1/repl1/ s/pat2/repl2/ ... I use this form of `command regex` in my `~/.lldbinit`, because it makes it clearer to write and read compared to a single line definition, because multiline substitutions don't need to be quoted, and are broken up one per line. However, multiline definitions result in usage instructions being printed for each use. The result is that every time I run `lldb`, I get a dozen or more lines of noise. With this change, the instructions are only printed when `command regex` is invoked interactively, or from a terminal, neither of which are true when lldb is sourcing `~/.lldbinit`. Reviewers: clayborg, jingham Reviewed By: clayborg Subscribers: jdoerfert, kastiglione, xiaobai, keith, lldb-commits Differential Revision: https://reviews.llvm.org/D48752 llvm-svn: 355793
* 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
* [lldb] Introduce StackFrameRecognizer [take 3]Kuba Mracek2018-10-311-0/+15
| | | | | | | | 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-15/+0
| | | | llvm-svn: 345688
* [lldb] Introduce StackFrameRecognizer [take 2]Kuba Mracek2018-10-311-0/+15
| | | | | | | | 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-15/+0
| | | | llvm-svn: 345680
* [lldb] Introduce StackFrameRecognizerKuba Mracek2018-10-311-0/+15
| | | | | | | | 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
* Add a "scripted" breakpoint type to lldb.Jim Ingham2018-09-131-1/+25
| | | | | | | | | | 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
* Get rid of the C-string parameter in DoExecuteRaphael Isemann2018-07-121-10/+9
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch gets rid of the C-string parameter in the RawCommandObject::DoExecute function, making the code simpler and less memory unsafe. There seems to be a assumption in some command objects that this parameter could be a nullptr, but from what I can see the rest of the API doesn't actually allow this (and other command objects and related code pieces dereference this parameter without any checks). Especially CommandObjectRegexCommand has error handling code for a nullptr that is now gone. Reviewers: davide, jingham, teemperor Reviewed By: teemperor Subscribers: jingham, lldb-commits Differential Revision: https://reviews.llvm.org/D49207 llvm-svn: 336955
* Partially revert r335236Pavel Labath2018-06-211-0/+8
| | | | | | | | | | 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-8/+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
* Remove dependency from Host to pythonPavel Labath2018-06-201-0/+6
| | | | | | | | | | | | | | | | Summary: The only reason python was used in the Host module was to compute the python path. I resolve this the same way as D47384 did for clang, by moving the path computation into the python plugin and modifying SBHostOS class to call into this module for ePathTypePythonDir. Reviewers: zturner, jingham, davide Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D48215 llvm-svn: 335104
* Revert r317182 for https://reviews.llvm.org/D39128Jason Molenda2017-11-021-4/+4
| | | | | | | 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-4/+4
| | | | | | | | | | | | | | | 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
* Ahhhh roll back that commit, I didn't see that Lawrence had filedJason Molenda2017-11-021-4/+4
| | | | | | | a separate phabracator with the revised change. This was his first atttempt which broke on the bots the second time too. llvm-svn: 317181
* Commit Lawrence D'Anna's patch to changeJason Molenda2017-11-021-4/+4
| | | | | | | | | | | | | | 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/D38829 llvm-svn: 317180
* Reverting r315966 - it caused a build failure on an ubuntu x android bot.Jason Molenda2017-10-171-4/+4
| | | | llvm-svn: 315967
* Committing this for Larry D'Anna:Jason Molenda2017-10-171-4/+4
| | | | | | | | | | | This patch adds support for passing an arbitrary python stream (anything inheriting from IOBase) to SetOutputFileHandle or SetErrorFileHandle. Differential revision: https://reviews.llvm.org/D38829 <rdar://problem/34870417> llvm-svn: 315966
* Rename Error -> Status.Zachary Turner2017-05-121-19/+19
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Fix serialization of Python breakpoint commands.Jim Ingham2016-09-261-0/+13
| | | | | | | | | | | CommandData breakpoint commands didn't know whether they were Python or Command line commands, so they couldn't serialize & deserialize themselves properly. Fix that. I also changed the "breakpoint list" command to note in the output when the commands are Python commands. Fortunately only one test was relying on this explicit bit of text output. llvm-svn: 282432
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-562/+505
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Add a few more needed bits to the scripted thread plans.Jim Ingham2016-08-051-0/+2
| | | | llvm-svn: 277879
* Add support for synthetic child providers to optionally return a customized ↵Enrico Granata2016-05-021-0/+2
| | | | | | typename for display llvm-svn: 268208
* Revert "Restore the lazy initialization of ScriptInterpreterPython, which ↵Pavel Labath2016-04-121-3/+3
| | | | | | | | | | was lost as part of the SystemLifetimeManager work" This change breaks python unit tests. This reverts commit 266033. llvm-svn: 266050
* Restore the lazy initialization of ScriptInterpreterPython, which was lost ↵Enrico Granata2016-04-121-3/+3
| | | | | | as part of the SystemLifetimeManager work llvm-svn: 266033
* Fixed the python interpreter so that it correctly inherits the top ↵Greg Clayton2016-03-101-0/+3
| | | | | | | | | | IOHandler's files instead of always using stdin/out/err. Removed lldb_private::File::Duplicate() and the copy constructor and the assignment operator that used to duplicate the file handles and made them private so no one uses them. Previously the lldb_private::File::Duplicate() function duplicated files that used file descriptors, (int) but not file streams (FILE *), so the lldb_private::File::Duplicate() function only worked some of the time. No one else excep thee ScriptInterpreterPython was using these functions, so that aren't needed nor desired. Previously every time you would drop into the python interpreter we would duplicate files, and now we avoid this file churn. <rdar://problem/24877720> llvm-svn: 263161
* Fix Clang-tidy modernize-use-override warnings in some files in ↵Eugene Zelenko2015-10-241-51/+63
| | | | | | source/Plugins; other minor fixes. llvm-svn: 251167
* [SBValue] Add a method GetNumChildren(uint32_t max)Siva Chandra2015-10-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-201-3/+3
| | | | llvm-svn: 250838
* Fix linkage of `init_lldb` SWIG method in Python 3.Zachary Turner2015-10-161-1/+5
| | | | llvm-svn: 250531
* Introduce a `PythonFile` object, and use it everywhere.Zachary Turner2015-10-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | 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
* Fix ref counting of Python objects.Zachary Turner2015-10-131-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 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
* Convert the ScriptInterpreter system to a plugin-based one.Zachary Turner2015-07-301-0/+590
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