summaryrefslogtreecommitdiffstats
path: root/lldb/scripts/Python/python-wrapper.swig
Commit message (Collapse)AuthorAgeFilesLines
* 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
* merge lldb-platform-work branch (and assorted fixes) into trunkDaniel Malea2013-08-261-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
* Second attempt at getting the PyCallable changes in trunkEnrico Granata2013-07-091-1403/+985
| | | | | | Thanks to Daniel Malea for helping test this patch for Linux happiness! llvm-svn: 185965
* Revert commits that cause broken builds on GCC buildbotsDaniel Malea2013-07-031-329/+757
| | | | | | | | - build fails due to PyCallable template definition inside an extern "C" scope This commit reverts 185240, 184893 and 184608. llvm-svn: 185560
* <rdar://problem/14309010>Enrico Granata2013-06-281-1/+2
| | | | | | | | OS Plugins' __init__ method takes two arguments: (self,process) I was erroneously passing the session_dict as well as part of my PyCallable changes and that caused plugins to fail to work llvm-svn: 185240
* <rdar://problem/14266411>Enrico Granata2013-06-251-22/+3
| | | | | | | | | | | | The semi-unofficial way of returning a status from a Python command was to return a string (e.g. return "no such variable was found") that LLDB would pick as a clue of an error having happened This checkin changes that: - SBCommandReturnObject now exports a SetError() call, which can take an SBError or a plain C-string - script commands now drop any return value and expect the SBCommandReturnObject ("return object") to be filled in appropriately - if you do nothing, a success will be assumed If your commands were relying on returning a value and having LLDB pick that up as an error, please change your commands to SetError() through the return object or expect changes in behavior llvm-svn: 184893
* Lots of cleanup on the SWIG wrapping layerEnrico Granata2013-06-211-746/+336
| | | | | | | | | | Now, the way SWIG wrappers call into Python is through a utility PyCallable object, which overloads operator () to look like a normal function call Plus, using the SBTypeToSWIGWrapper() family of functions, we can call python functions transparently as if they were plain C functions Using this new technique should make adding new Python call points easier and quicker The PyCallable is a generally useful facility, and we might want to consider moving it to a separate layer where other parts of LLDB can use it llvm-svn: 184608
* Change the SWIG wrappers to stop directly casting SB object to SWIG objects, ↵Enrico Granata2013-06-211-18/+18
| | | | | | | | | | | and instead use a safer type-checked API (thanks templates) Any time a SWIG wrapper needs a PyObject for an SB object, it now should call into SBTypeToSWIGWrapper<SBType>(SBType*) If you try to use it on an SBType for which there is not an implementation yet, LLDB will fail to link - just add your specialization to python-swigsafecast.swig and rebuild This is the first step in simplifying our SWIG Wrapper layer llvm-svn: 184580
* In thread and frame format strings, it is now allowed to use Python ↵Enrico Granata2013-06-201-0/+344
| | | | | | | | | | | | | | | functions to generate part or all of the output text Specifically, the ${target ${process ${thread and ${frame specifiers have been extended to allow a subkeyword .script:<fctName> (e.g. ${frame.script:FooFunction}) The functions are prototyped as def FooFunction(Object,unused) where object is of the respective SB-type (SBTarget for target.script, ... and so on) This has not been implemented for ${var because it would be akin to a Python summary which is already well-defined in LLDB llvm-svn: 184500
* Making our Python decrefs NULL-safeEnrico Granata2013-06-111-17/+17
| | | | llvm-svn: 183774
* <rdar://problem/13759177>Enrico Granata2013-06-111-1/+7
| | | | | | | Allowing LLDB to resolve names of Python functions when they are located in classes This allows things like *bound* classmethods to be used for formatters, commands, ... llvm-svn: 183772
* This checkin enables Python summaries to return any string-convertible objectEnrico Granata2013-05-301-2/+12
| | | | | | | | Upon encountering an object not of type string, LLDB will get the string representation of it (akin to calling str(X) in Python code) and use that as the summary to display Feedback is welcome as to whether repr() should be used instead (but the argument for repr() better be highly persuasive :-) llvm-svn: 182953
* <rdar://problem/13883385>Enrico Granata2013-05-151-0/+4
| | | | | | | | | | | Python breakpoint actions can return False to say that they don't want to stop at the breakpoint to which they are associated Almost all of the work to support this notion of a breakpoint callback was in place, but two small moving parts were missing: a) the SWIG wrapper was not checking the return value of the script b) when passing a Python function by name, the call statement was dropping the return value of the function This checkin addresses both concerns and makes this work Care has been taken that you only keep running when an actual value of False has been returned, and that any other value (None included) means Stop! llvm-svn: 181866
* Since we use C++11, we should switch over to using std::unique_ptr when ↵Greg Clayton2013-04-181-2/+2
| | | | | | | | C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++. Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro. llvm-svn: 179779
* Remove std::string input arguments and replace with "const char *".Greg Clayton2013-01-161-9/+12
| | | | llvm-svn: 172647
* Match extern "C" in declaration and definition (swig template)Daniel Malea2012-11-291-0/+8
| | | | | | - Fix for building with gcc 4.6 llvm-svn: 168901
* <rdar://problem/12523238> Commit 1 of 3Enrico Granata2012-10-231-65/+97
| | | | | | | | | | | | This commit enables the new HasChildren() feature for synthetic children providers Namely, it hooks up the required bits and pieces so that individual synthetic children providers can implement a new (optional) has_children call Default implementations have been provided where necessary so that any existing providers continue to work and behave correctly Next steps are: 2) writing smart implementations of has_children for our providers whenever possible 3) make a test case llvm-svn: 166495
* <rdar://problem/12437442>Enrico Granata2012-10-221-0/+1
| | | | | | | | | | | Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar* If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was no trivial way for us to change the SP inside an SBValue on the fly This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM) As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases) llvm-svn: 166426
* Fixing a potential control may reach end of non-void function issueEnrico Granata2012-08-271-0/+1
| | | | llvm-svn: 162685
* Added SBDebugger's log callbacks to Python-landFilipe Cabecinhas2012-08-251-28/+42
| | | | | | | | | | | | | | | | | | | - Tweaked a parameter name in SBDebugger.h so my typemap will catch it; - Added a SBDebugger.Create(bool, callback, baton) to the swig interface; - Added SBDebugger.SetLoggingCallback to the swig interface; - Added a callback utility function for log callbacks; - Guard against Py_None on both callback utility functions; - Added a FIXME to the SBDebugger API test; - Added a __del__() stub for SBDebugger. We need to be able to get both the log callback and baton from an SBDebugger if we want to protect against memory leaks (or make the user responsible for holding another reference to the callback). Additionally, it's impossible to revert from a callback-backed log mechanism to a file-backed log mechanism. llvm-svn: 162633
* Fixing a bunch of issues with the OS plugin codeEnrico Granata2012-08-241-1/+1
| | | | llvm-svn: 162527
* Adding bindings to the Script Interpreter for some basic Python OS plugin ↵Enrico Granata2012-08-241-0/+97
| | | | | | functionality (still WIP) llvm-svn: 162513
* Fixed a Linux building bug pointed out by Daniel Malea.Filipe Cabecinhas2012-08-221-1/+1
| | | | llvm-svn: 162373
* Added a typemap and wrappers for SBInputReader callbacksFilipe Cabecinhas2012-08-221-0/+56
| | | | | | | | | | | | | | Now it's possible to use SBInputReader callbacks in Python. We leak the callback object, unfortunately. A __del__ method can be added to SBInputReader, but we have no way to check the callback function that is on the reader. So we can't call Py_DECREF on it when we have our PythonCallback function. One way to do it is to assume that reified SBInputReaders always have a Python callback (and always call Py_DECREF). Another one is to add methods or properties to SBInputReader (or make the m_callback_function property public). llvm-svn: 162356
* rdar://problem/11457143 [ER] need "watchpoint command ..."Johnny Chen2012-08-091-0/+79
| | | | | | Add 'watchpoint command add/delete/list' to lldb, plus two .py test files. llvm-svn: 161638
* Massive enumeration name changes: a number of enums in ValueObject were not ↵Enrico Granata2012-03-191-5/+13
| | | | | | | | | | | | | | | | | | following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
* This commit:Enrico Granata2012-02-291-91/+65
| | | | | | | | | | | | | a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
* Add more robustness - use PyString_CheckExact(pvalue) to check whether ↵Johnny Chen2011-12-141-1/+1
| | | | | | | | pvalue is a Python string before calling PyString_AsString(pvalue). Similar to http://llvm.org/viewvc/llvm-project?rev=146584&view=rev. llvm-svn: 146606
* http://llvm.org/bugs/show_bug.cgi?id=11569Johnny Chen2011-12-141-2/+4
| | | | | | | | | | LLDBSwigPythonCallCommand crashes when a command script returns an object Add more robustness to LLDBSwigPythonCallCommand. It should check whether the returned Python object is a string, and only assign it as the error msg when the check holds. Also add a regression test. llvm-svn: 146584
* this patch introduces a new command script import command which takes as ↵Enrico Granata2011-10-171-1/+83
| | | | | | input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
* Redesign of the interaction between Python and frozen objects:Enrico Granata2011-09-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
* Additional code cleanups ; Short option name for --python-script in type ↵Enrico Granata2011-08-231-2/+0
| | | | | | summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
* - Support for Python namespaces:Enrico Granata2011-08-221-206/+133
| | | | | | | | | | | If you have a Python module foo, in order to use its contained objects in LLDB you do not need to use 'from foo import *'. You can use 'import foo', and then refer to items in foo as 'foo.bar', and LLDB will know how to resolve bar as a member of foo. Accordingly, GNU libstdc++ formatters have been moved from the global namespace to gnu_libstdcpp and a few test cases are also updated to reflect the new convention. Python docs suggest using a plain 'import' en lieu of 'from-import'. llvm-svn: 138244
* Further fix for SWIG interoperability; making sure the Release() method of ↵Enrico Granata2011-08-201-13/+30
| | | | | | SBCommandReturnObject is called at all times llvm-svn: 138169
* Fixed some SWIG interoperability issuesEnrico Granata2011-08-191-13/+26
| | | | llvm-svn: 138154
* Taking care of an issue with using lldb_private types in ↵Enrico Granata2011-08-191-2/+2
| | | | | | SBCommandInterpreter.cpp ; Making NSString test case work on Snow Leopard ; Removing an unused variable warning llvm-svn: 138105
OpenPOWER on IntegriCloud