summaryrefslogtreecommitdiffstats
path: root/lldb/scripts/Python/python-wrapper.swig
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Changes to Python commands:Enrico Granata2011-08-161-4/+6
| | | | | | | | | | | | - They now have an SBCommandReturnObject instead of an SBStream as third argument - The class CommandObjectPythonFunction has been merged into CommandObjectCommands.cpp - The command to manage them is now: command script with subcommands add, list, delete, clear command alias is returned to its previous functionality - Python commands are now part of an user dictionary, instead of being seen as aliases llvm-svn: 137785
* Python commands:Enrico Granata2011-08-161-0/+140
| | | | | | | | | | | | | It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
* Fixed an issue where LLDB was complaining about the lack of 'update' in a ↵Enrico Granata2011-08-111-0/+15
| | | | | | synthetic provider, despite it being optional llvm-svn: 137330
* adding required utility function to SWIG interfaceEnrico Granata2011-07-261-0/+43
| | | | llvm-svn: 136147
* lldb.swig (the SWIG input file) has become too large. Modularize a bit by ↵Johnny Chen2011-07-261-0/+527
introducing two files to be included from lldb.swig: python-typemaps.swig and python-wrapper.swig. llvm-svn: 136117
OpenPOWER on IntegriCloud