summaryrefslogtreecommitdiffstats
path: root/lldb/scripts/Python
Commit message (Collapse)AuthorAgeFilesLines
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-067-337/+544
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Fixup TestPyObjSynthProvider.py and enable it againPavel Labath2016-08-311-0/+1
| | | | | | | | | | | | | | | Summary: - copies the new file in the cmake build - adds an additional import statement - marks the test as no-debug-info specific, as it seems to be testing a python feature Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D24074 llvm-svn: 280261
* Add an helper class lldb.formatters.synth.PythonObjectSyntheticChildProviderEnrico Granata2016-08-301-0/+1
| | | | | | | | This class enables one to easily write a synthetic child provider by writing a class that returns pairs of names and primitive Python values - the base class then converts those into LLDB SBValues Comes with a test case llvm-svn: 280172
* Add .i files for SBMemoryRegionInfo and SBMemoryRegionInfoList and also hook ↵Greg Clayton2016-06-241-0/+16
| | | | | | | | up the new calls in SBProcess that give out SBMemoryRegionInfo and SBMemoryRegionInfoList objects. Also make sure the right headers and .i files are included so SWIG can hook everything up. llvm-svn: 273749
* Fix an issue where the @lldb.command marker would not work with the new ↵Enrico Granata2016-06-242-5/+10
| | | | | | | | | | | 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
* Create _lldb python symlink correctly when LLVM_LIBDIR_SUFFIX is usedFrancis Ricci2016-04-251-6/+36
| | | | | | | | | | | | | | | | Summary: Do not assume that liblldb.so is located in $(lldb -P)/../../../lib when creating the _lldb python symlink. Instead, use the path passed to LLVM_LIBDIR_SUFFIX, defaulting to $(lldb -P)/../../../lib when this variable is not set. Reviewers: vharron, emaste, zturner Subscribers: zturner, labath, lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19067 llvm-svn: 267462
* Fix #ifdef __APPLE__ code is the swig Python bindingsTodd Fiala2016-04-081-2/+2
| | | | | | | | | | This code was getting evaluated unintentionally at binding generation time instead of binding file compilation time. Addresses: https://bugs.swift.org/browse/SR-1192 llvm-svn: 265829
* Fix a build issue where the python module could become stale.Zachary Turner2016-03-181-4/+17
| | | | | | | | | | | | | | | | | We are using hardlinks instead of symlinks, and we attempted to have some logic where we don't re-create the link if the target file already exists. This logic is faulty, however, when you manually delete the source file (e.g. liblldb.dll) and then rebuild lldb so that a brand new liblldb.dll gets written. Now the two files have different inodes, but the target exists, so we would not remake the link and the target would become stale. We fix this by only doing the optimization if they are really the exact same file (by comparing inode numbers), and if they are not the same file but the target exists, we delete it and re-create the link. llvm-svn: 263844
* Check for a NULL input filehandle before referencing it.Jim Ingham2016-03-111-8/+11
| | | | | | <rdar://problem/25105824> llvm-svn: 263274
* Fix SBDebugger.GetOutputFileHandle() on OS X.Jim Ingham2016-03-112-2/+4
| | | | | | | | | | | | | | | | | | | | | | | The swig typemaps had some magic for output File *'s on OS X that made: SBDebugger.GetOutputFileHandle() actually work. That was protected by a "#ifdef __MACOSX__", but the corresponding define got lost going from the Darwin shell scripts to the python scripts for running swig, so the code was elided. I need to pass the define to SWIG, but only when targetting Darwin. So I added a target-platform argument to prepare_bindings, and if that is Darwin, I pass -D__APPLE__ to swig, and that activates this code again, and GetOutputFileHandle works again. Note, I only pass that argument for the Xcode build. I'm sure it is possible to do that for cmake, but my cmake-foo is weak. I should have been able to write a test for this by creating a debugger, setting the output file handle to something file, writing to it, getting the output file handle and reading it. But SetOutputFileHandle doesn't seem to work from Python, so I'd have to write a pexpect test to test this, which I'd rather not do. llvm-svn: 263183
* Adjust for Python-3.Siva Chandra2016-02-121-5/+29
| | | | | | | | | | | | | | | Summary: This does not yet give us a clean testsuite run but it does help with: 1. Actually building on linux 2. Run the testsuite with over 70% tests passing on linux. Reviewers: tfiala, labath, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17182 llvm-svn: 260721
* Change lldb.value.__int__() so that it takes into account the signedness of ↵Enrico Granata2016-02-101-3/+48
| | | | | | | | | | the value being cast to return a Python number with the proper value The explicit APIs on SBValue obviously remain if one wants to be explicit in intent, or override this guess, but since __int__() has to pick one, an educated guess is definitely better than than always going to signed regardless Fixes rdar://24556976 llvm-svn: 260349
* Remove autoconf support from source directories.Eugene Zelenko2016-01-283-135/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* Fix some issues with bytes and strings in Python 3.Zachary Turner2016-01-251-3/+8
| | | | | | | | | | | | | | | | | | SBProcess::ReadMemory and other related functions such as WriteMemory are returning Python string() objects. This means that in Python 3 that are returning Unicode objects. In reality they should be returning bytes objects which is the same as a string in Python 2, but different in Python 3. This patch updates the generated SWIG code to return Python bytes objects for all memory related functions. One quirk of this patch is that the C++ signature of ReadCStringFromMemory has it writing c-string data into a void*. This confuses our swig typemaps which expect that a void* means byte data. So I hacked up a custom typemap which maps this specific function to treat the void* as string data instead of byte data. llvm-svn: 258743
* Fix more occurrences of string/bytes/bytearray in swig typemaps.Zachary Turner2016-01-251-20/+44
| | | | llvm-svn: 258742
* Fix swig typemap for SBEvent.Zachary Turner2016-01-251-6/+14
| | | | | | | | | | | This needs to be able to handle bytes, strings, and bytearray objects. In Python 2 this was easy because bytes and strings are the same thing, but in Python 3 the 2 cases need to be handled separately. So as not to mix raw Python C API code with PythonDataObjects code, I've also introduced a PythonByteArray class to PythonDataObjects to make the paradigm used here consistent. llvm-svn: 258741
* Fix ResourceWarning about unclosed file in use_lldb_suite_root.py.Zachary Turner2016-01-151-3/+6
| | | | llvm-svn: 257945
* Get rid of const char** typemaps.Zachary Turner2016-01-131-70/+7
| | | | | | | | We already have char** typemaps which were near copy-pastes of the const char** versions. This way we have only one version that works for both. llvm-svn: 257670
* Fix TestProcessLaunch for Python 3.Zachary Turner2016-01-131-21/+29
| | | | | | | | | | | | | | | | | | There were a number of problems preventing this from working: 1. The SWIG typemaps for converting Python lists to and from C++ arrays were not updated for Python 3. So they were doing things like PyString_Check instead of using the PythonString from PythonDataObjects. 2. ProcessLauncherWindows was ignoring the environment completely. So any test that involved launching an inferior with any kind of environment variable would have failed. 3. The test itself was using process.GetSTDOUT(), which isn't implemented on Windows. So this was changed to save the value of the environment variable in a local variable and have the debugger look at the value of the variable. llvm-svn: 257669
* Fix an issue where scripted commands would not actually print any of their ↵Enrico Granata2016-01-131-1/+3
| | | | | | | | output if an immediate output file was set in the result object via a Python file object Fixes rdar://24130303 llvm-svn: 257644
* Fix Python 3 issues related to OS plugins.Zachary Turner2016-01-111-9/+11
| | | | | | | | | | * lldb::tid_t was being converted incorrectly, so this is updated to use PythonInteger instead of manual Python Native API calls. * OSPlugin_RegisterContextData was assuming that the result of get_register_data was a string, when in fact it is a bytes. So this method is updated to use PythonBytes to do the work. llvm-svn: 257398
* __ne__ is the actual Python operator; __neq__ is a typoEnrico Granata2015-12-181-1/+1
| | | | llvm-svn: 256053
* Change finishSwigPythonLLDB.py to copy six.py instead of simlink itTed Woodward2015-12-111-11/+26
| | | | | | | | | | | | Summary: If six.py is simlink'd, an installation won't be able to find it unless it has access to the source tree that lldb was built from. Reviewers: zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D15422 llvm-svn: 255340
* Remove `lldb.root` and just look for the file we care about.Zachary Turner2015-11-201-1/+1
| | | | llvm-svn: 253679
* Revert "prepare_bindings.py: enable static bindings"Todd Fiala2015-11-193-83956/+7
| | | | | | This reverts commit 40f789f2dc6bb80fd25a33f91e452d081ed9d0ee. llvm-svn: 253575
* Remove superseded buildSwigWrapperClasses.py and buildSwigPython.py classesTodd Fiala2015-11-181-782/+0
| | | | | | | This closes: http://reviews.llvm.org/D14783 llvm-svn: 253513
* Remove the scripts/Python/build-swig-Python.sh script.Todd Fiala2015-11-181-378/+0
| | | | | | This logically goes with my previous commit. llvm-svn: 253491
* Fix some issues with swig & string conversion.Zachary Turner2015-11-181-5/+16
| | | | | | | | | | | | | | | | | | | | This patch fixes two issues: 1) Popen needs to be used with universal_newlines=True by default. This elicits automatic decoding from bytes -> string in Py3, and has no negative effects in other Py versions. 2) The swig typemaps for converting between string and (char*, int) did not work correctly when the length of the string was 0, indicating an error. In this case we would try to construct a string from uninitialized data. 3) Ironically, the bug mentioned in #2 led to a test passing on Windows that was actually broken, because the test was written such that the assertion was never even getting checked, so it passed by default. So we additionally fix this test to also fail if the method errors. By fixing this test it's now broken on Windows, so we also xfail it. llvm-svn: 253487
* prepare_bindings.py: enable static bindingsTodd Fiala2015-11-183-7/+83956
| | | | | | | | | | | | | | | Added a new flag, --allow-static-binding. When specified, if (and only if) the swig binary cannot be found, then the LLDBWrapPython.cpp and lldb.py from the scripts/Python/{static-binding-dir} are copied into the place where swig would have generated them. {static-binding-dir} defaults to static-binding, and can be overridden with the --static-binding-dir command line argument. The static bindings checked in are from r253424. llvm-svn: 253448
* Add Pythonic language binding wrapper generation script.Todd Fiala2015-11-171-0/+435
| | | | | | | | | | | | | | | | | | | | | | | | This is only used by Xcode at the moment. It replaces the buildSwigWrapperClasses.py and related per-script-language scripts. It also fixes a couple bugs in those w/r/t Xcode usage: * the presence of the GCC_PREPROCESSOR_DEFINITIONS env var should not be short-circuiting generation of the language binding; rather, only if LLDB_DISABLE_PYTHON is present within that environment variable. * some logic around what to do when building in "non-Makefile" mode. I've switched the handling of that to be on a "--framework" flag - if specified, we build an OS X-style framework; otherwise, we go with non. Putting this up now only attached to the Xcode build so others can look at it but not be affected by it yet. After this, I'll tackle the finalizer, along with trying it locally on Linux. llvm-svn: 253317
* Insert the SWIG version into LLDB's __init__.pyZachary Turner2015-11-161-5/+30
| | | | | | | The goal here is to allow us to add skip / xfail decorators based on SWIG version. llvm-svn: 253262
* Python3 - Fix some issues related to `PythonFile` class.Zachary Turner2015-11-161-0/+5
| | | | | | | | Python 3 has lots of new debug asserts, and some of these were firing on PythonFile. Specifically related to handling of invalid files. llvm-svn: 253261
* Allow to override python-config executable name from command lineBruce Mitchener2015-11-151-1/+2
| | | | | | | | | | | | | | Summary: pkgsrc (on NetBSD) ships with python2.7-config. Patch by Kamil Rytarowski. Thanks! Reviewers: emaste, clayborg Subscribers: brucem, lldb-commits, joerg Differential Revision: http://reviews.llvm.org/D14528 llvm-svn: 253152
* 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
* Symlink the `six` module during swig generation.Zachary Turner2015-11-111-22/+43
| | | | llvm-svn: 252764
* Fixed TypeMemberFunctionImpl to not use clang types directly but use the new ↵Greg Clayton2015-11-101-0/+14
| | | | | | | | | | CompilerDecl class to do the job in an abstract way. Fixed a crash that would happen if you tried to get the name of a constructor or destructor by calling "getDeclName()" instead of calling getName() (which would assert and crash). Added the ability to get function arguments names from SBFunction. llvm-svn: 252622
* 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
* Remove a debug print statement.Zachary Turner2015-11-071-1/+0
| | | | llvm-svn: 252384
* Python 3 - Use __bool__() instead of __nonzero__() for truthiness.Zachary Turner2015-11-072-1/+38
| | | | | | | | | | | | | | | | | | | | | | | Python has a complicated mechanism of checking an objects truthity. This involves a number of steps, which end with calling two private methods on an object (if they are implemented). In Python 2 these two methods are `__nonzero__` and `__len__`, and in Python 3 they are `__bool__` and `__len__`. Because we *also* define a __len__ method for certain iterable types, this was triggering a situation in Python 3 where `__nonzero__` wasn't defined, so it was calling `__len__`, which was returning 0 (for example an SBDebugger with no targets), and as a result the truthosity was determined to be False. We fix this by correctly using ` __bool__` for Python 3, and leave the behavior under Python 2 unchanged. Note that this fix is only implemented in the SWIG generation python script, and not the SWIG generation shell script. Someone more familiar than me with shell scripts will need to fix them to support this for Python 3 if desired. llvm-svn: 252382
* [swig] Remove check_lldb_swig_executable_file_exists.Bruce Mitchener2015-11-061-33/+21
| | | | | | | | | | | | | | | | | Summary: Code that tried to find swig and then split the path into a separate path and filename is being removed. The invoking build system always provides the location of swig and we don't need to split it into 2 pieces only to recombine it a short time later. Reviewers: zturner, domipheus Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14415 llvm-svn: 252330
* [swig] Start of pylint on python build scripts.Bruce Mitchener2015-11-053-1059/+1053
| | | | | | | | | | | | | | | | | | | | | | | Summary: This does a broad first pass on cleaning up a lot of the noise when using pylint on these scripts. It mostly addresses issues of: * Mixed tabs and spaces. * Trailing whitespace. * Semicolons where they aren't needed. * Incorrect whitespace around () and []. * Superfluous parentheses. There will be subsequent patches with further changes that build upon these. Reviewers: zturner, domipheus Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14375 llvm-svn: 252244
* Revert "Python 3 - Don't add the _d suffix to the symlink on Windows."Zachary Turner2015-11-041-4/+2
| | | | | | | | | | | | This reverts commit e59c95ca936f5a0a8abb987b8605fd8bf82b03b6. This was a mistake on my part. The real problem was with my environment. I was using a release interpreter to try to load my debug extension module. I noticed this after I finally managed to get into my extension module's init method, and then it segfaulted with heap errors due to mismatched CRT (debug vs. release) llvm-svn: 252030
* Python 3 - Don't add the _d suffix to the symlink on Windows.Zachary Turner2015-11-041-2/+4
| | | | | | | | | | | In Python 2, a debug extension module required an _d suffix, so for example the extension module `_lldb` would be backed by the file `_lldb_d.pyd` if built in debug mode, and `_lldb.pyd` if built in release mode. In Python 2, although undocumented, this seems to no longer be the case, and even for a debug extension module, the interpreter will only look for the `_lldb.pyd` name. llvm-svn: 252026
* Revert part of r239007 related to creating the Python symlink.Zachary Turner2015-11-021-9/+0
| | | | | | | | | | | | | | | This has apparently been broken since June, but only on non-Windows. Perhaps nobody noticed it because if the symlink is already there it won't try to re-create it, and nobody ever tried doing a clean build. In any case, I will let the original author attempt to fix this if he is still interested. the problem is that in the normal case of not setting BUILD_SHARED_LIBS and simply running ninja, it would link _lldb.so to a non-existent location, creating a dangling symlink. llvm-svn: 251840
* Rename argdumper to lldb-argdumperTodd Fiala2015-10-292-13/+13
| | | | | | http://reviews.llvm.org/D14169 llvm-svn: 251616
OpenPOWER on IntegriCloud