summaryrefslogtreecommitdiffstats
path: root/lldb/scripts/Python/python-wrapper.swig
Commit message (Collapse)AuthorAgeFilesLines
* [lldb/Bindings] Move bindings into their own subdirectoryJonas Devlieghere2020-01-091-1074/+0
| | | | | | | | | | | | All the code required to generate the language bindings for Python and Lua lives under scripts, even though the majority of this code aren't scripts at all, and surrounded by scripts that are totally unrelated. I've reorganized these files and moved everything related to the language bindings into a new top-level directory named bindings. This makes the corresponding files self contained and much more discoverable. Differential revision: https://reviews.llvm.org/D72437
* [LLDB][Python] remove ArgInfo::countLawrence D'Anna2019-11-041-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch updates the last user of ArgInfo::count and deletes it. I also delete `GetNumInitArguments()` and `GetInitArgInfo()`. Classess are callables and `GetArgInfo()` should work on them. On python 3 it already works, of course. `inspect` is good. On python 2 we have to add yet another special case. But hey if python 2 wasn't crufty we wouln't need python 3. I also delete `is_bound_method` becuase it is unused. This path is tested in `TestStepScripted.py` Reviewers: labath, mgorny, JDevlieghere Reviewed By: labath, JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D69742
* [LLDB][breakpoints] ArgInfo::count -> ArgInfo::max_positional_argsLawrence D'Anna2019-10-291-20/+22
| | | | | | | | | | | | | | | | | | | | Summary: Move breakpoints from the old, bad ArgInfo::count to the new, better ArgInfo::max_positional_args. Soon ArgInfo::count will be no more. It looks like this functionality is already well tested by `TestBreakpointCommandsFromPython.py`, so there's no need to write additional tests for it. Reviewers: labath, jingham, JDevlieghere Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D69468
* [LLDB][formatters] ArgInfo::count -> ArgInfo::max_positional_argsLawrence D'Anna2019-10-271-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Move breakpoints from the old, bad ArgInfo::count to the new, better ArgInfo::max_positional_args. Soon ArgInfo::count will be no more. This functionality is tested in `TestFormatters.py`, `TestDataFormatterSynthVal.py`, `TestDataFormatterSynthType.py`. You may notice that the old code was passing 0 arguments when count was 1, and passing 1 argument when count is 2. This is no longer necessary because max_positional_args counts the self pointer correctly. Reviewers: labath, jingham, JDevlieghere Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D69469
* Add the ability to pass extra args to a Python breakpoint callback.Jim Ingham2019-10-251-2/+15
| | | | | | | | | | | | | | | | | 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
* remove multi-argument form of PythonObject::Reset()Lawrence D'Anna2019-10-221-43/+0
| | | | | | | | | | | | | | | | | | | | Summary: With this patch, only the no-argument form of `Reset()` remains in PythonDataObjects. It also deletes PythonExceptionState in favor of PythonException, because the only call-site of PythonExceptionState was also using Reset, so I cleaned up both while I was there. Reviewers: JDevlieghere, clayborg, labath, jingham Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D69214 llvm-svn: 375475
* convert LLDBSwigPythonCallTypeScript to ArgInfo::max_positional_argsLawrence D'Anna2019-10-191-5/+10
| | | | | | | | | | | | | | | | | | | | Summary: This patch converts another user of ArgInfo::count over to use ArgInfo::max_positional_args instead. I also add a test to make sure both documented signatures for python type formatters work. Reviewers: JDevlieghere, clayborg, labath, jingham Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D69153 llvm-svn: 375334
* [LLDB] bugfix: command script add -f doesn't work for some callablesLawrence D'Anna2019-10-191-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [lldb] Fix crash on SBCommandReturnObject & assignmentJan Kratochvil2019-10-041-28/+2
| | | | | | | | | | | | | | | | | I was writing an SB API client and it was crashing on: bool DoExecute(SBDebugger dbg, char **command, SBCommandReturnObject &result) { result = subcommand(dbg, "help"); That is because SBCommandReturnObject &result gets initialized inside LLDB by: bool DoExecute(Args &command, CommandReturnObject &result) override { // std::unique_ptr gets initialized here from `&result`!!! SBCommandReturnObject sb_return(&result); DoExecute(...); sb_return.Release(); Differential revision: https://reviews.llvm.org/D67589 llvm-svn: 373775
* [lldb] Fix typo in r373675Sam McCall2019-10-041-1/+1
| | | | llvm-svn: 373719
* Pass an SBStructuredData to scripted ThreadPlans on use.Jim Ingham2019-10-031-1/+18
| | | | | | | | | | 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
* 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
* [Python] Update PyString_FromString() to work for python 2 and 3.Davide Italiano2019-01-091-1/+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
* Add a "scripted" breakpoint type to lldb.Jim Ingham2018-09-131-0/+95
| | | | | | | | | | 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
* 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
* Fix an issue where the @lldb.command marker would not work with the new ↵Enrico Granata2016-06-241-1/+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
* Delete `PyObjectToString` and use `PythonObject::Str()`.Zachary Turner2015-11-131-43/+12
| | | | | | | The latter function, from PythonDataObjects, is Python 3 ready and the former was not. llvm-svn: 252992
* Finish PyCallable -> PythonCallable conversion.Zachary Turner2015-11-121-258/+88
| | | | | | | | | | | | | | This finishes the effort to port python-wrapper.swig code over to using PythonDataObjects. Also included in this patch is the removal of `PyCallable` from `python-wrapper.swig`, as it is no longer used after having been replaced by `PythonCallable` everywhere. There might be additional cleanup as followup patches, but it should be all fairly simple and minor. llvm-svn: 252939
* 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-213/+157
| | | | | | | | | | | | | | | | 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
* Remove `FindSessionDictionary` and rely on PythonDataObjects.Zachary Turner2015-11-111-190/+140
| | | | | | | | This had been relegated to a simple forwarding function, so just delete it in preparation of migrating all of these functions out of python-wrapper.swig. llvm-svn: 252803
* Convert python-wrapper.swig to use PythonDataObjects.Zachary Turner2015-11-111-99/+43
| | | | | | | | | This only begins to port python-wrapper.swig over. Since this code can be pretty hairy, I plan to do this incrementally over a series of patches, each time removing or converting more code over to the PythonDataObjects code. llvm-svn: 252788
* Use PythonDataObjects in swig helper functions.Zachary Turner2015-11-091-31/+31
| | | | | | | | | | | | | | | | | Relying on manual Python C API calls is error prone, especially when trying to maintain compatibility with Python 2 and Python 3. This patch additionally fixes what appears to be a potentially serious memory leak, in that were were incref'ing two values returned from the session dictionary but never decref'ing them. There was a comment indicating that it was intentional, but the reasoning was, I believe, faulty and it resulted in a legitimate memory leak. Switching everything to PythonObject based classes solves both the compatibility issues as well as the resource leak issues. llvm-svn: 252536
* [SBValue] Add a method GetNumChildren(uint32_t max)Siva Chandra2015-10-211-6/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [LLDBSwigPythonCallTypeScript] Remove redundant call to type summary func.Siva Chandra2015-06-251-2/+0
| | | | | | | | | | | | Reviewers: clayborg, granata.enrico Reviewed By: clayborg, granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10625 llvm-svn: 240698
* Fix the clang -Werror build & make the unit tests link under LinuxDavid Blaikie2015-03-171-16/+10
| | | | | | | | The order of libraries passed to the linker didn't work under linux (you need the llvm libraries first, then the lldb libraries). I modelled this after clang's setup here. Seemed simple enough to just be consistent. llvm-svn: 232461
* Handle PyLong return values in LLDBSwigPython_CalculateNumChildren.Siva Chandra2015-03-161-4/+24
| | | | | | | | | | | | | | | | | | | | | | Summary: Also, change its return type to size_t to match the return types of its callers. With this change, std::vector and std::list data formatter tests pass on Linux (when using libstdc++) with clang as well as with gcc. These tests have also been enabled in this patch. Test Plan: dotest.py -p <TestDataFormatterStdVector|TestDataFormatterStdList> Reviewers: vharron, clayborg Reviewed By: clayborg Subscribers: zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D8337 llvm-svn: 232399
* Strip trailing whitespace from python-wrapper.swigEd Maste2015-03-141-158/+158
| | | | | | (To test the dependency added in r232256.) llvm-svn: 232257
* Bulk of the infrastructure work to allow script commands to be backed by ↵Enrico Granata2015-03-131-0/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | object instances in addition to free functions This works by creating a command backed by a class whose interface should - at least - include def __init__(self, debugger, session_dict) def __call__(self, args, return_obj, exe_ctx) What works: - adding a command via command script add --class - calling a thusly created command What is missing: - support for custom help - test cases The missing parts will follow over the next couple of days This is an improvement over the existing system as: a) it provides an obvious location for commands to provide help strings (i.e. methods) b) it allows commands to store state in an obvious fashion c) it allows us to easily add features to script commands over time (option parsing and subcommands registration, I am looking at you :-) llvm-svn: 232136
* Enable Python summaries to use custom SBTypeSummaryOptions if the user is so ↵Enrico Granata2014-11-221-1/+10
| | | | | | inclined. Updates to the webdoc will follow llvm-svn: 222593
* Add a feature where a string data formatter can now be partially composed of ↵Enrico Granata2014-10-281-0/+38
| | | | | | | | | | | | | | Python summary functions This works similarly to the {thread/frame/process/target.script:...} feature - you write a summary string, part of which is ${var.script:someFuncName} someFuncName is expected to be declared as def someFuncName(SBValue,otherArgument) - essentially the same as a summary function Since . -> [] are the only allowed separators, and % is used for custom formatting, .script: would not be a legitimate symbol anyway, which makes this non-ambiguous llvm-svn: 220821
* Remove unnecessary update of 'name' local.Jason Molenda2014-10-161-1/+0
| | | | | | clang static analyzer fixit. llvm-svn: 219892
* Extend synthetic children to produce synthetic values (as in, those that ↵Enrico Granata2014-10-081-0/+28
| | | | | | | | | | | | | | | | | GetValueAsUnsigned(), GetValueAsCString() would return) The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function. If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value The rationale for doing things this way is twofold: - there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial - we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature Comes with a test case llvm-svn: 219330
* Allow Python commands to optionally take an SBExecutionContext argument in ↵Enrico Granata2014-10-011-2/+9
| | | | | | case they need to handle 'where they want to act' separately from the notion of 'currently-selected entity' that is associated to the debugger. Do this in an (hopefully) non-breaking way by running an argcount check before passing in the new argument. Update the test case to also check for this new feature. www update to follow llvm-svn: 218834
* Add an accessor to PyCallable that allows one to determine the count of ↵Enrico Granata2014-10-011-1/+26
| | | | | | arguments that a Python function allows, and whether varargs/kwargs are also accepted by the same function llvm-svn: 218812
* This checkin is the first step in making the lldb thread stepping mechanism ↵Jim Ingham2014-09-291-0/+112
| | | | | | | | | | | | more accessible from the user level. It adds the ability to invent new stepping modes implemented by python classes, and to view the current thread plan stack and to some extent alter it. I haven't gotten to documentation or tests yet. But this should not cause any behavior changes if you don't use it, so its safe to check it in now and work on it incrementally. llvm-svn: 218642
* Make sure we don't try to print the SystemExit exception, or we will cause ↵Enrico Granata2014-02-181-1/+1
| | | | | | the containing process to exit() from under us llvm-svn: 201600
* <rdar://problem/15936507>Enrico Granata2014-01-291-0/+1
| | | | | | | | PyTuple_SetItem steals a reference to the item it inserts in the tuple This, plus the Py_XDECREF of the tuple a few lines below, causes our session dictionary to go away after the first time a SWIG layer function is called - with disastrous effects for the first subsequent attempt to use any functionality in ScriptInterpreterPython This fixes it llvm-svn: 200429
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-52/+1
| | | | | | | | | | | | The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
* Adding a document that describes the architecture of data formatters. ↵Enrico Granata2013-12-261-3/+1
| | | | | | Suggestions and ideas for improvements most welcome llvm-svn: 198038
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-3/+3
| | | | | | | | | | pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-021-3/+3
| | | | | | | | | | | | | | | | | | | | | defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods. Update all callers to use Frame*/Frame& instead of pointers to StackFrames. This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet. I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point. <rdar://problem/15314068> llvm-svn: 193907
* <rdar://problem/14972424>Greg Clayton2013-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When debugging with the GDB remote in LLDB, LLDB uses special packets to discover the registers on the remote server. When those packets aren't supported, LLDB doesn't know what the registers look like. This checkin implements a setting that can be used to specify a python file that contains the registers definitions. The setting is: (lldb) settings set plugin.process.gdb-remote.target-definition-file /path/to/module.py Inside module there should be a function: def get_dynamic_setting(target, setting_name): This dynamic setting function is handed the "target" which is a SBTarget, and the "setting_name", which is the name of the dynamic setting to retrieve. For the GDB remote target definition the setting name is 'gdb-server-target-definition'. The return value is a dictionary that follows the same format as the OperatingSystem plugins follow. I have checked in an example file that implements the x86_64 GDB register set for people to see: examples/python/x86_64_target_definition.py This allows LLDB to debug to any archticture that is support and allows users to define the registers contexts when the discovery packets (qRegisterInfo, qHostInfo) are not supported by the remote GDB server. A few benefits of doing this in Python: 1 - The dynamic register context was already supported in the OperatingSystem plug-in 2 - Register contexts can use all of the LLDB enumerations and definitions for things like lldb::Format, lldb::Encoding, generic register numbers, invalid registers numbers, etc. 3 - The code that generates the register context can use the program to calculate the register context contents (like offsets, register numbers, and more) 4 - True dynamic detection could be used where variables and types could be read from the target program itself in order to determine which registers are available since the target is passed into the python function. This is designed to be used instead of XML since it is more dynamic and code flow and functions can be used to make the dictionary. llvm-svn: 192646
* Add the capability for LLDB to query an arbitrary Python module (passed in ↵Enrico Granata2013-10-141-0/+24
| | | | | | | | | | | as a file path) for target-specific settings This is implemented by means of a get_dynamic_setting(target, setting_name) function vended by the Python module, which can respond to arbitrary string names with dynamically constructed settings objects (most likely, some of those that PythonDataObjects supports) for LLDB to parse This needs to be hooked up to the debugger via some setting to allow users to specify which module will vend the information they want to supply llvm-svn: 192628
* Convert to UNIX line endings.Joerg Sonnenberger2013-09-251-998/+998
| | | | llvm-svn: 191367
OpenPOWER on IntegriCloud