summaryrefslogtreecommitdiffstats
path: root/lldb/scripts
Commit message (Collapse)AuthorAgeFilesLines
...
* new api class: SBFileLawrence D'Anna2019-10-033-1/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: SBFile is a scripting API wrapper for lldb_private::File This is the first step in a project to enable arbitrary python io.IOBase file objects -- including those that override the read() and write() methods -- to be used as the main debugger IOStreams. Currently this is impossible because python file objects must first be converted into FILE* streams by SWIG in order to be passed into the debugger. full prototype: https://github.com/smoofra/llvm-project/tree/files Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath Reviewed By: labath Subscribers: labath, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67793 llvm-svn: 373562
* File::Clear() -> File::TakeStreamAndClear()Lawrence D'Anna2019-10-011-3/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: File::Clear() is an ugly function. It's only used in one place, which is the swig typemaps for FILE*. This patch refactors and renames that function to make it clear what it's really for and why nobody else should use it. Both File::TakeStreamAndClear() and the FILE* typemaps will be removed in later patches after a suitable replacement is in place. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68160 llvm-svn: 373285
* 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
* Fix some swig warningsPavel Labath2019-09-275-21/+3
| | | | | | | | | Previously, these were unseen because the wrapper script would swallow them. This fixes the following types of warnings: - methods being declared more than once - swig complained about ignoring operator=, so I just removed it llvm-svn: 373069
* Convert FileSystem::Open() to return Expected<FileUP>Lawrence D'Anna2019-09-261-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
* [lldb] Excludes private headers from SWIG dependency.Haibo Huang2019-09-251-0/+6
| | | | | | | | | | | | Reviewers: xiaobai Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68040 llvm-svn: 372905
* [lldb] Move swig call from python code to cmakeHaibo Huang2019-09-253-629/+24
| | | | | | | | | | | | | | Summary: Elimiates lots of unused code. Reviewers: labath, mgorny Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68007 llvm-svn: 372895
* [lldb] [cmake] Fix installing Python modules on systems using /usr/libMichal Gorny2019-09-252-10/+13
| | | | | | | | | | | | | | | Fix installing Python modules on systems that use /usr/lib for Python while installing other libraries in /usr/lib64. Rewrite CMake logic to query correct directories from Python, similarly to how prepare_binding_Python.py does it. Furthermore, change the regex used in get_relative_lib_dir.py to allow 'lib' without suffix. I think that the code can be further improved but I'd like to take this enterprise in smaller steps in case one of them breaks something. Differential Revision: https://reviews.llvm.org/D67890 llvm-svn: 372835
* prepare_binding_Python: print readable errors if SWIG failsJonas Devlieghere2019-09-201-4/+6
| | | | | | | | | | | | When swig fails, all the errors are squished onto one line with \n quoting. It's very hard to read. This will print them out in a more reasonable format. Patch by: Lawrence D'Anna Differential revision: https://reviews.llvm.org/D67790 llvm-svn: 372442
* Revert "Fix swig python package path"Haibo Huang2019-09-201-6/+4
| | | | | | | | | | | | | | Summary: This reverts commit 5a115e81cdd40c758b10c382aeffc0c8de6930e2. Reviewers: JDevlieghere, ZeGentzy Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67781 llvm-svn: 372364
* Fix command-script-import.test on linuxPavel Labath2019-09-181-4/+4
| | | | | | | | | | | | | | | | | | The test was expecting the value of "lldb.frame" to be None, because it is cleared after each python interpreter session. However, this is not true in the very first session, because lldb.py sets these values to invalid objects (lldb.SBFrame(), etc.). I have not investigated why is it that this test passes on darwin, but my guess is that this is because we do extra work on darwin (loading the objc runtime, etc), which causes us to enter the python interpreter sooner. This patch changes lldb.py to also initialize these values to None, as that seems to make more sense. I also fixed some typos in the test while I was in there. llvm-svn: 372222
* Fix swig python package pathHaibo Huang2019-09-161-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The path defined in CMakeLists.txt doesn't match the path generated in our python script. This change fixes that. LLVM_LIBRARY_OUTPUT_INTDIR is defined as: ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX}) On the other hand, the path of site-package is generaged in get_framework_python_dir_windows() in finishSwigPythonLLDB.py as: (Dispite its name, the function is used for everything other than xcode) prefix/cmakeBuildConfiguration/distutils.sysconfig.get_python_lib() From lldb/CMakeLists.txt, we can see that: prefix=${CMAKE_BINARY_DIR}, cmakeBuildConfiguration=${CMAKE_CFG_INTDIR} And from python source code, we can see get_python_lib() always returns lib/pythonx.y/site-packages for posix, or Lib/site-packages for windows: https://github.com/python/cpython/blob/3.8/Lib/distutils/sysconfig.py#L128 We should make them match each other. Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67583 llvm-svn: 372047
* [Python] Implement __next__ for value_iterJonas Devlieghere2019-09-041-1/+4
| | | | | | | | | Python 3 iteration calls the next() method instead of next() and value_iter only implemented the Python 2 version. Differential revision: https://reviews.llvm.org/D67184 llvm-svn: 370954
* [Python] Implement truth testing for lldb.valueJonas Devlieghere2019-09-041-0/+3
| | | | | | | | | Python 3 calls __bool__() instead of __len__() and lldb.value only implemented the __len__ method. This adds the __bool__() implementation. Differential revision: https://reviews.llvm.org/D67183 llvm-svn: 370953
* [Python] Fix whitespace before making changes (NFC)Jonas Devlieghere2019-09-041-164/+164
| | | | llvm-svn: 370952
* [lldb] Remove Xcode project legacyStefan Granitz2019-07-2413-1761/+0
| | | | | | | | | | | | | | Summary: Since D65109 removed the manually maintained Xcode project, there's a few things we don't need anymore. Anything here we should keep or anything more to remove? Reviewers: JDevlieghere, jasonmolenda, clayborg, jingham, lanza, teemperor Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D65155 llvm-svn: 366879
* Remove Xcode project remnantsJonas Devlieghere2019-07-221-56/+0
| | | | llvm-svn: 366745
* [LLDB] Remove the Xcode projectJonas Devlieghere2019-07-221-251/+0
| | | | | | | | | | | | | Finally, after a lot of hard work from a bunch of people, we're in a state where we can unify LLDB's build system. This patch removes the hand-maintained Xcode project in favor of using CMake in combination with the Xcode generator. Going forward, we want to focus our efforts on improving the generated Xcode project. Differential revision: https://reviews.llvm.org/D65109 llvm-svn: 366739
* [lldb][swig] Fix autodocs flag parsingJordan Rupprecht2019-07-181-1/+1
| | | | | | | | r366471 added "-features autodoc" without a trailing comment, leading to `Unrecognized option -features autodoc-threads` due to implicit string concatenation. Add a comma to fix that. Also separate into "-features" and "autodoc", otherwise it gets parsed as a single "-features autodoc" flag which is also not recognized (it must be two separate CLI args). llvm-svn: 366478
* [swig] Enable autodoc featureJonas Devlieghere2019-07-181-0/+1
| | | | | | | | | This patch enables the SWIG `autodoc` feature so that the generated Python reference [1] includes class properties. [1] https://lldb.llvm.org/python_reference/index.html llvm-svn: 366471
* Revert "[swig] Add workaround for old swig"Jonas Devlieghere2019-07-161-5/+0
| | | | | | | With the deprecation of swig 1.x (r366213), this workaround should no longer be necessary. llvm-svn: 366221
* [SWIG] Deprecate SWIG 1.xJonas Devlieghere2019-07-161-0/+5
| | | | | | | | | | | | | | The last swig 1.x release dates from 2009, now 10 years ago. Recently, I fixed an issue that prevented us from using swig 4 (r364974), which turned out to be not backward compatible with swig 1.x (r365718). This patch deprecates this (really old) version of swig and makes swig 2 the minimum supported version in LLDB . This should be fine for the build bots, which are all running swig 3 or later. Differential revision: https://reviews.llvm.org/D64782 llvm-svn: 366213
* [swig] Add workaround for old swigJonas Devlieghere2019-07-111-0/+5
| | | | | | | | | Apparently, when using swig 1.3.40, properties to set values do not work without the `__swig_setmethods__` workaround. I conditionally added this back for SBTypeCategory, as it's causing a test failure on GreenDragon, while I investigate this further. llvm-svn: 365718
* [scripts] Remove the unused 'shush' script.Davide Italiano2019-07-101-64/+0
| | | | | | | | There are pre-made utilities doing this. If somebody finds an use for it and wants to resurrect, I would recommend to revise the error messages. llvm-svn: 365677
* [swig] Don't mess with swig internals.Jonas Devlieghere2019-07-0231-842/+287
| | | | | | | | | | | | | | | As of SWIG 4.0, __swig_getmethods__ and __swig_setmethods__ are no longer defined. It appears that there's no need to mess with these internals, we can simplify define the corresponding properties inline. Originally I wanted to use the swig extension %attribute and %attributeref to define properties. However, I couldn't find a way to add documentation to these attributes. Since we already had the properties defined inline, we might as well keep them. Differential revision: https://reviews.llvm.org/D63530 llvm-svn: 364974
* Revert "[swig] Define attribute(ref) instead of accessing swig internals."Jonas Devlieghere2019-07-0210-114/+289
| | | | | | This reverts commit f9b91a52797325ccaaee229e414beae7c03f1948. llvm-svn: 364951
* [swig] Define attribute(ref) instead of accessing swig internals.Jonas Devlieghere2019-07-0210-289/+114
| | | | | | | | | | | As of SWIG 4.0, __swig_getmethods__ and __swig_setmethods__ are no longer defined. The solution is to stop using these internal swig dictionaries and use %attribute and %attributeref instead. I plan on doing this incrementally, with this differential serving as an example. Differential revision: https://reviews.llvm.org/D63530 llvm-svn: 364946
* Make SBDebugger.RunCommandInterpreter callable from Python.Jim Ingham2019-05-151-0/+26
| | | | | | | | Authored by: Lukas Boger Differential Revision: https://reviews.llvm.org/D61602 llvm-svn: 360730
* Kill modify-python-lldb.pyPavel Labath2019-04-243-189/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: After the last round of cleanups, this script was almost a no-op. The only piece of functionality that remained was the one which tried to make the swig-generated function signatures more pythonic. The "tried" part is important here, as it wasn't doing a really good job and the end result was not valid python nor c (e.g., SetExecutable(SBAttachInfo self, str const * path)). Doing these transformations another way is not possible, as these signatures are generated by swig, and not present in source. However, given that this is the only reason why we need a swig post-process step, and that the current implementation is pretty sub-optimal, this patch simply abandons the signature fixup idea, and chooses to simplify our build process instead. Reviewers: amccarth, jingham, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D61000 llvm-svn: 359092
* modify-python-lldb: Remove \a-removing codePavel Labath2019-04-235-23/+19
| | | | | | instead, remove \a directly from the interface files. llvm-svn: 358967
* modify-python-lldb.py: Remove docstring formatting codePavel Labath2019-04-213-79/+60
| | | | | | | | | | | The strings have been already cleaned up in r358683, so this code is not doing anything anymore. While comparing the outputs before and after removing the formatting code, I've found a couple of docstrings that managed to escape my perl script in r358683, so I format them manually with this patch. llvm-svn: 358846
* Clean up docstrings in swig interface filesPavel Labath2019-04-1855-1824/+1563
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch removes the "//----" frames and "///" leading lines from docstring comments. We already have code doing transformations like this in modify-python-lldb.py, but that's a script I'd like to remove. Instead of running these transformations everytime we run swig, we can just perform equivalent on its input once. This patch can be reproduced (e.g. for downstream merges) with the following "sweet" perl command: perl -i -p -e 'BEGIN{ $/ = undef;} s:(" *\n) *//-----*\n:\1:gs; s:^( *)/// ?:\1:gsm; s:^ *//------*\n( *\n)?( *"):\2:gsm; s: *$::gsm; s:\n *"\):"):gsm' scripts/interface/*.i This command produces nearly equivalent python files to those produced by the relevant code in modify-python-lldb.py. The only difference I noticed is that here I am slightly more agressive in removing trailing newlines from docstring comments (the python script seems to leave newlines in class-level docstrings). Reviewers: amccarth, clayborg, jingham, aprantl Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60498 llvm-svn: 358683
* [Shell] Simplify Extracting Python VersionJonas Devlieghere2019-04-181-2/+1
| | | | | | | Instead of parsing the Python version with a fairly convoluted regex, just print the major and minor version and call it a day. llvm-svn: 358635
* Docstringify some comments in the swig interface filesPavel Labath2019-04-103-4/+8
| | | | | | Without these, the comments don't end up in the generated python code. llvm-svn: 358055
* Remove unneeded #ifdef SWIGsPavel Labath2019-04-091-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Some of these were present in files which should never be read by swig (and we also had one in the interface file, which is only read by swig). They are probably leftovers from the time when we were running swig over lldb headers directly. While writing this patch, I noticed that some of the #ifdefs were guarding public functions that were operating on lldb_private data types. While it wasn't strictly necessary for this patch, I made these private, as nobody should really be accessing them. This can potentially break existing code if it happened to use these methods, though it will only break at build time -- if someone builds against an old header, he should still be able to link to a new lldb library, since the functions are still there. We could keep these public for backward compatbility, but I would argue that if anyone was actually using these functions for anything, his code is already broken. Reviewers: JDevlieghere, clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60400 llvm-svn: 357984
* modify-python-lldb.py: Remove ifdef SWIG-removing codePavel Labath2019-04-081-13/+4
| | | | | | | | | There are no patterns like that in the generated swig files (there probably were some back in the days when we were running swig over the header files directly), so this is dead code and has no effect on the generated file. llvm-svn: 357890
* modify-python-lldb.py: Insert initialization code with swig insteadPavel Labath2019-04-052-7/+10
| | | | | | | | This is the last functional change to the generated python module being done by modify-python-lldb.py. The remaining code just deals with reformatting of comments. llvm-svn: 357755
* modify-python-lldb.py: (Re)move __len__ and __iter__ supportPavel Labath2019-04-043-106/+26
| | | | | | | | | | | | | | | | Summary: This patch moves the modify-python-lldb code for adding new functions to the SBModule class into the SBModule interface file. As this is the last class using this functionality, I also remove all support for this kind of modifications from modify-python-lldb.py. Reviewers: amccarth, clayborg, jingham Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D60195 llvm-svn: 357680
* modify-python-lldb.py: clean up __iter__ and __len__ supportPavel Labath2019-04-0314-36/+117
| | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of modifying the swig-generated code, just add the appropriate methods to the interface files in order to get the swig to do the generation for us. This is a straight-forward move from the python script to the interface files. The single class which has nontrivial handling in the script (SBModule) has been left for a separate patch. For the cases where I did not find any tests exercising the iteration/length methods (i.e., no tests failed after I stopped emitting them), I tried to add basic tests for that functionality. Reviewers: zturner, jingham, amccarth Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D60119 llvm-svn: 357572
* Make operator==s consistent between c++ and python APIsPavel Labath2019-04-027-45/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: modify-python-lldb.py had code to insert python equality operators to some classes. Some of those classes already had c++ equality operators, and some didn't. This makes the situation more consistent, by removing all equality handilng from modify-python-lldb. Instead, I add c++ operators to classes where they were missing, and expose them in the swig interface files so that they are available to python too. The only tricky case was the SBAddress class, which had an operator== defined as a free function, which is not handled by swig. This function cannot be removed without breaking ABI, and we cannot add an extra operator== member, as that would make equality comparisons ambiguous. For this class, I define a python __eq__ function by hand and have it delegate to the operator!=, which I have defined as a member function. This isn't fully NFC, as the semantics of some equality functions in python changes slightly, but I believe it changes for the better (e.g., previously SBBreakpoint.__eq__ would consider two breakpoints with the same ID as equal, even if they belonged to different targets; now they are only equal if they belong to the same target). Reviewers: jingham, clayborg, zturner Subscribers: jdoerfert, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D59819 llvm-svn: 357463
* [Cmake] Unify python variablesJonas Devlieghere2019-03-291-2/+0
| | | | | | | | | | | | | | | | | | | | FindPythonInterp and FindPythonLibs do two things, they set some variables (PYTHON_LIBRARIES, PYTHON_INCLUDE_DIRS) and update the cached variables (PYTHON_LIBRARY, PYTHON_INCLUDE_DIR) which are also used to specify a custom python installation. I believe the canonical way to do this is to use the PYTHON_LIBRARIES and PYTHON_INCLUDE_DIRS variables instead of the cached ones. However, since the cached variables are accessible from the cache and GUI, this is a lot less confusing when you're trying to debug why a variable did or didn't get the value you expected. Furthermore, as far as I can tell, the implementation uses the cached variables to set their LIBRARIES/DIRS counterparts. This is also the reason this works today even though we mix-and-match. Differential revision: https://reviews.llvm.org/D59968 llvm-svn: 357282
* [Python] Remove readline moduleJonas Devlieghere2019-03-294-128/+0
| | | | | | | | | | | Todd added this empty readline module to workaround an issue with an old version of Python on Ubuntu in 2014 (18841). In the meantime, libedit seems to have fixed the underlying issue, and indeed, I wasn't able to reproduce this. Differential revision: https://reviews.llvm.org/D59972 llvm-svn: 357277
* Fix the swig typemap for "uint32_t *versions, uint32_t num_versions".Jim Ingham2019-03-281-10/+5
| | | | | | | | | It was making a list of a certain size but not always filling in that many elements, which would lead to a crash iterating over the list. Differential Revision: https://reviews.llvm.org/D59913 llvm-svn: 357207
* python 2/3 compat: commands vs subprocessSerge Guelton2019-03-261-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D59584 llvm-svn: 356995
* Python 2/3 compatibility: from __future__ import print_functionSerge Guelton2019-03-216-48/+50
| | | | | | Differential Revision: https://reviews.llvm.org/D59580 llvm-svn: 356695
* Workaround Python's map difference between Python2/3Serge Guelton2019-03-211-2/+4
| | | | | | | | | When the output of map is not used, using a list comprehension or an explicit call to list looks awkward. Differential Revision: https://reviews.llvm.org/D59587 llvm-svn: 356672
* Use list comprehension instead of map/filter to prepare Python2/3 compatSerge Guelton2019-03-212-6/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D59579 llvm-svn: 356647
* Fix/unify SBType comparisonPavel Labath2019-03-132-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In my next step at cleaning up modify-python-lldb.py, I started focusing on equality comparison. To my surprise, I found out that both python and c++ versions of the SBType class implement equality comparison, but each one does it differently. While the python version was implemented in terms of type name equality, the C++ one used a deep comparison on the underlying objects. Removing the python version caused one test to fail (TestTypeList). This happened because the c++ version of operator== boiled down to TypePair::operator==, which contains two items: the compiler_type and type_sp. In this case, the compiler_type was identical, but one of the objects had the type_sp field unset. I tried fixing the code so that both objects keep their type_sp member, but it wasn't easy, because there are so many operations which just work with the CompilerType types, and so any operation on the SBType (the test in question was doing GetPointeeType on the type of one variable and expecting it to match the type of another variable), cause that second member to be lost. So instead, here I relax the equality comparison on the TypePair class. Now, this class ignores the type_sp for the purposes of comparison, and uses the CompilerType only. This seems reasonable, as each TypeSP is able to convert itself to a CompilerType. Reviewers: clayborg, aprantl, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D59217 llvm-svn: 356048
* Add "operator bool" to SB APIsPavel Labath2019-03-1157-18/+124
| | | | | | | | | | | | | | | | | | | | | | | Summary: Our python version of the SB API has (the python equivalent of) operator bool, but the C++ version doesn't. This is because our python operators are added by modify-python-lldb.py, which performs postprocessing on the swig-generated interface files. In this patch, I add the "operator bool" to all SB classes which have an IsValid method (which is the same logic used by modify-python-lldb.py). This way, we make the two interfaces more constent, and it allows us to rely on swig's automatic syntesis of python __nonzero__ methods instead of doing manual fixups. Reviewers: zturner, jingham, clayborg, jfb, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58792 llvm-svn: 355824
* [build] Rename clang-headers to clang-resource-headersShoaib Meenai2019-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current install-clang-headers target installs clang's resource directory headers. This is different from the install-llvm-headers target, which installs LLVM's API headers. We want to introduce the corresponding target to clang, and the natural name for that new target would be install-clang-headers. Rename the existing target to install-clang-resource-headers to free up the install-clang-headers name for the new target, following the discussion on cfe-dev [1]. I didn't find any bots on zorg referencing install-clang-headers. I'll send out another PSA to cfe-dev to accompany this rename. [1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits Tags: #clang, #sanitizers, #lldb, #openmp, #llvm Differential Revision: https://reviews.llvm.org/D58791 llvm-svn: 355340
OpenPOWER on IntegriCloud