aboutsummaryrefslogtreecommitdiff
path: root/lldb/scripts/Python/modify-python-lldb.py
AgeCommit message (Collapse)AuthorFilesLines
2019-04-24Kill modify-python-lldb.pyPavel Labath1-141/+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
2019-04-23modify-python-lldb: Remove \a-removing codePavel Labath1-4/+0
instead, remove \a directly from the interface files. llvm-svn: 358967
2019-04-21modify-python-lldb.py: Remove docstring formatting codePavel Labath1-15/+1
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
2019-04-08modify-python-lldb.py: Remove ifdef SWIG-removing codePavel Labath1-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
2019-04-05modify-python-lldb.py: Insert initialization code with swig insteadPavel Labath1-7/+0
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
2019-04-04modify-python-lldb.py: (Re)move __len__ and __iter__ supportPavel Labath1-100/+3
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
2019-04-03modify-python-lldb.py: clean up __iter__ and __len__ supportPavel Labath1-35/+4
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
2019-04-02Make operator==s consistent between c++ and python APIsPavel Labath1-43/+8
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
2019-03-13Fix/unify SBType comparisonPavel Labath1-1/+0
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
2019-03-11Add "operator bool" to SB APIsPavel Labath1-15/+0
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
2019-02-27Insert blocks of python code with swig instead of modify-python-lldb.pyPavel Labath1-125/+0
Summary: Swig is perfectly capable of inserting blocks of python code into its output (and we use those fascilities already), so there's no need for this to be done in a post-process step. lldb_iter is a general-purpose utility used from many classes, so I add it to the main swig file. The other two blocks are tied to a specific class, so I add it to the interface file of that class. Reviewers: zturner, jingham, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58350 llvm-svn: 354975
2019-02-15Embed swig version into lldb.py in a different wayPavel Labath1-22/+1
Summary: Instead of doing string chopping on the resulting python file, get swig to output the version for us. The two things which make slightly non-trivial are: - in order to get swig to expand SWIG_VERSION for us, we cannot use %pythoncode directly, but we have to go through an intermediate macro. - SWIG_VERSION is a hex number, but it's components are supposed to be interpreted decimally, so there is a bit of integer magic needed to get the right number to come out. I've tested that this approach works both with the latest (3.0.12) and oldest (1.3.40) supported swig. Reviewers: zturner, jingham, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58172 llvm-svn: 354104
2016-09-06*** This commit represents a complete reformatting of the LLDB source codeKate Stone1-52/+66
*** 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
2015-11-16Insert the SWIG version into LLDB's __init__.pyZachary Turner1-5/+30
The goal here is to allow us to add skip / xfail decorators based on SWIG version. llvm-svn: 253262
2015-11-07Remove a debug print statement.Zachary Turner1-1/+0
llvm-svn: 252384
2015-11-07Python 3 - Use __bool__() instead of __nonzero__() for truthiness.Zachary Turner1-1/+16
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
2015-11-05[swig] Start of pylint on python build scripts.Bruce Mitchener1-1/+1
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
2015-10-06Update swig generation scripts to support Python 3.Zachary Turner1-3/+7
llvm-svn: 249467
2012-12-10Make sure that the lldb globals:Greg Clayton1-2/+8
lldb.target lldb.process lldb.thread lldb.frame are initialized to at least contain empty lldb classes in case some python gets imported that uses them. llvm-svn: 169750
2012-11-01Makefile patches from Charles Davis and Daniel Malea (+ one or two tweaks).Filipe Cabecinhas1-1/+1
llvm-svn: 167242
2012-03-16Export the APIs submitted by Dawn to the Python bindings. Add a simple test ↵Johnny Chen1-1/+5
case for the SBModule.compile_unit_iter() API. llvm-svn: 152952
2011-11-08Add a missing ')' in the comment.Johnny Chen1-1/+1
llvm-svn: 144145
2011-10-14SBValue::Watch() and SBValue::WatchPointee() are now the official API for ↵Johnny Chen1-3/+3
creating a watchpoint for either the variable encapsulated by SBValue (Watch) or the pointee encapsulated by SBValue (WatchPointee). Removed SBFrame::WatchValue() and SBFrame::WatchLocation() API as a result of that. Modified the watchpoint related test suite to reflect the change. Plus replacing WatchpointLocation with Watchpoint throughout the code base. There are still cleanups to be dome. This patch passes the whole test suite. Check it in so that we aggressively catch regressions. llvm-svn: 141925
2011-10-13Cleaned up the SBWatchpoint public API.Greg Clayton1-1/+1
llvm-svn: 141876
2011-10-03Add comment markers for in_range(symbol, section).Johnny Chen1-0/+3
llvm-svn: 141033
2011-09-30Add docstring to in_range() function residing in the lldb module.Johnny Chen1-0/+1
llvm-svn: 140833
2011-09-30Migrate the in_range(symbol, section) and symbol_iter(module, section) ↵Johnny Chen1-5/+40
utility functions from lldbutil.py to the lldb.py proper. The in_range() function becomes a function in the lldb module. And the symbol_iter() function becomes a method within the SBModule called symbol_in_section_iter(). Example: # Iterates the text section and prints each symbols within each sub-section. for subsec in text_sec: print INDENT + repr(subsec) for sym in exe_module.symbol_in_section_iter(subsec): print INDENT2 + repr(sym) print INDENT2 + 'symbol type: %s' % symbol_type_to_str(sym.GetType()) might produce this following output: [0x0000000100001780-0x0000000100001d5c) a.out.__TEXT.__text id = {0x00000004}, name = 'mask_access(MaskAction, unsigned int)', range = [0x00000001000017c0-0x0000000100001870) symbol type: code id = {0x00000008}, name = 'thread_func(void*)', range = [0x0000000100001870-0x00000001000019b0) symbol type: code id = {0x0000000c}, name = 'main', range = [0x00000001000019b0-0x0000000100001d5c) symbol type: code id = {0x00000023}, name = 'start', address = 0x0000000100001780 symbol type: code [0x0000000100001d5c-0x0000000100001da4) a.out.__TEXT.__stubs id = {0x00000024}, name = '__stack_chk_fail', range = [0x0000000100001d5c-0x0000000100001d62) symbol type: trampoline id = {0x00000028}, name = 'exit', range = [0x0000000100001d62-0x0000000100001d68) symbol type: trampoline id = {0x00000029}, name = 'fflush', range = [0x0000000100001d68-0x0000000100001d6e) symbol type: trampoline id = {0x0000002a}, name = 'fgets', range = [0x0000000100001d6e-0x0000000100001d74) symbol type: trampoline id = {0x0000002b}, name = 'printf', range = [0x0000000100001d74-0x0000000100001d7a) symbol type: trampoline id = {0x0000002c}, name = 'pthread_create', range = [0x0000000100001d7a-0x0000000100001d80) symbol type: trampoline id = {0x0000002d}, name = 'pthread_join', range = [0x0000000100001d80-0x0000000100001d86) symbol type: trampoline id = {0x0000002e}, name = 'pthread_mutex_lock', range = [0x0000000100001d86-0x0000000100001d8c) symbol type: trampoline id = {0x0000002f}, name = 'pthread_mutex_unlock', range = [0x0000000100001d8c-0x0000000100001d92) symbol type: trampoline id = {0x00000030}, name = 'rand', range = [0x0000000100001d92-0x0000000100001d98) symbol type: trampoline id = {0x00000031}, name = 'strtoul', range = [0x0000000100001d98-0x0000000100001d9e) symbol type: trampoline id = {0x00000032}, name = 'usleep', range = [0x0000000100001d9e-0x0000000100001da4) symbol type: trampoline [0x0000000100001da4-0x0000000100001e2c) a.out.__TEXT.__stub_helper [0x0000000100001e2c-0x0000000100001f10) a.out.__TEXT.__cstring [0x0000000100001f10-0x0000000100001f68) a.out.__TEXT.__unwind_info [0x0000000100001f68-0x0000000100001ff8) a.out.__TEXT.__eh_frame llvm-svn: 140830
2011-09-27Add SBTarget::GetLastCreatedWatchpointLocation() API and export to the ↵Johnny Chen1-5/+6
Python interface. Also add rich comparison methods (__eq__ and __ne__) for SBWatchpointLocation. Modify TestWatchpointLocationIter.py to exercise the new APIs. Add fuzz testings for the recently added SBTarget APIs related to watchpoint manipulations. llvm-svn: 140633
2011-09-27Export the watchpoint related API (SBWatchpointLocation class and added ↵Johnny Chen1-2/+5
SBTarget methods) to the Python interface. Implement yet another (threre're 3 now) iterator protocol for SBTarget: watchpoint_location_iter(), to iterate on the available watchpoint locations. And add a print representation for SBWatchpointLocation. Exercise some of these Python API with TestWatchpointLocationIter.py. llvm-svn: 140595
2011-09-24SBSection supports iteration through its subsections, represented as ↵Johnny Chen1-1/+9
SBSection as well. SBModule supports an additional SBSection iteration, besides the original SBSymbol iteration. Add docstrings and implement the two SBSection iteration protocols. llvm-svn: 140449
2011-08-11Add logic to SBValue.linked_list_iter() to detect infinite loop and to bail ↵Johnny Chen1-1/+5
out early. Add code to test case to create an evil linked list with: task_evil -> task_2 -> task_3 -> task_evil ... and to check that the linked list iterator only iterates 3 times. llvm-svn: 137291
2011-08-11Change the SBValue.linked_list_iter() to treat the value object as a ↵Johnny Chen1-2/+4
homogeneous linked list data structure where an empty linked list is represented as a value object with a NULL value, instead of a special value object which 'points' to NULL. Also modifies the test case to comply. rdar://problem/9933692 llvm-svn: 137289
2011-08-05o modify-python-lldb.py:Johnny Chen1-2/+3
Add the rich comparison methods (__eq__, __ne__) to SBType, too. o lldbtest.py: Add debug utility method TestBase.DebugSBType(). o test/python_api/type: Add tests for exercising SBType/SBTypeList API, including the SBTarget.FindTypes(type_name) API which returns a SBTypeList matching the type_name. llvm-svn: 136975
2011-08-05The recently introduced SBTypeList is also iterable.Johnny Chen1-2/+3
This patch takes some time because the old Python constructor pattern was not a valid one, and breaks with SBTypeList's __init__ signature. Oops. llvm-svn: 136958
2011-07-27The SBValue.linked_list_iter() API failed for an empty list.Johnny Chen1-3/+1
Fix the bug and add a test case. llvm-svn: 136265
2011-07-26We can do better with the SBValue.linked_list_iter() API by supplying a defaultJohnny Chen1-12/+16
end of list test function as __eol_test__. The simple example can be reduced to: for t in task_head.linked_list_iter('next'): print t Modify the test program to exercise the API for both cases: supplying or not supplying an end of list test function. llvm-svn: 136144
2011-07-26The test function to determine whether we have reached the end of the list wasJohnny Chen1-14/+7
too complex in the test case. We can just simply test that the SBValue object is a valid object and it does not correspond to a null pointer in order to say that EOL has not been reached. Modify the test case and the lldb.py docstring to have a more compact test function. llvm-svn: 136123
2011-07-25Rename the parameter for the end-of-list test function from end_of_list to ↵Johnny Chen1-2/+2
end_of_list_test. llvm-svn: 136016
2011-07-25Add cross references between the docstrings for regular SBValue iteration:Johnny Chen1-5/+11
for child in value: # do something with the child value and SBValue.linked_list_iter(): for task in task_head.linked_list_iter('next', eol_test): # visit each item in the linked list llvm-svn: 136015
2011-07-25Provide an add-on API to SBValue class by post-processing to provide a wayJohnny Chen1-0/+61
to iterate through an SBValue instance by treating it as the head of a linked list. API program must provide two args to the linked_list_iter() method: the first being the child member name which points to the next item on the list and the second being a Python function which an SBValue (for the next item) and returns True if end of list is reached, otherwise it returns False. For example, suppose we have the following sample program. #include <stdio.h> class Task { public: int id; Task *next; Task(int i, Task *n): id(i), next(n) {} }; int main (int argc, char const *argv[]) { Task *task_head = new Task(-1, NULL); Task *task1 = new Task(1, NULL); Task *task2 = new Task(2, NULL); Task *task3 = new Task(3, NULL); // Orphaned. Task *task4 = new Task(4, NULL); Task *task5 = new Task(5, NULL); task_head->next = task1; task1->next = task2; task2->next = task4; task4->next = task5; int total = 0; // Break at this line Task *t = task_head; while (t != NULL) { if (t->id >= 0) ++total; t = t->next; } printf("We have a total number of %d tasks\n", total); return 0; } The test program produces the following output while exercising the linked_list_iter() SBVAlue API: task_head: TypeName -> Task * ByteSize -> 8 NumChildren -> 2 Value -> 0x0000000106400380 ValueType -> local_variable Summary -> None IsPointerType -> True Location -> 0x00007fff65f06e60 (Task *) next = 0x0000000106400390 (int) id = 1 (Task *) next = 0x00000001064003a0 (Task *) next = 0x00000001064003a0 (int) id = 2 (Task *) next = 0x00000001064003c0 (Task *) next = 0x00000001064003c0 (int) id = 4 (Task *) next = 0x00000001064003d0 (Task *) next = 0x00000001064003d0 (int) id = 5 (Task *) next = 0x0000000000000000 llvm-svn: 135938
2011-07-16Create an interface file for SBTarget named SBTarget.i which relieves SBTarget.hJohnny Chen1-15/+44
of the duty of having SWIG docstring features and multiline string literals embedded within. lldb.swig now %include .../SBTarget.i, instead of .../SBTarget.h. Will create other interface files and transition them over. Also update modify-python-lldb.py to better handle the trailing blank line right before the ending '"""' Python docstring delimiter. llvm-svn: 135355
2011-07-15Add some more docstrings for SBCompileUnit and SBBreakpoint, plus ↵Johnny Chen1-3/+4
incorporate the doxgen doc block of SBValue::GetChildAtIndex(uint32_t idx, lldb::DynamicValueType use_dynamic, bool can_create_synthetic); into the SBValue docstrings. llvm-svn: 135295
2011-07-14Add some more docstrings (includng example usages) to SBTarget.h.Johnny Chen1-0/+3
Add logic to modify-python-lldb to correct swig's transformation of 'char **argv' and 'char **envp' to 'char argv' and 'char envp' by morphing them into the 'list argv' and 'list envp' (as a list of Python strings). llvm-svn: 135114
2011-07-08Missed the char_to_str_xform on the docstrings for the module level function ↵Johnny Chen1-1/+3
definitions. llvm-svn: 134775
2011-07-06Add post-processing step to transform the docstring from 'char', i.e., 'char ↵Johnny Chen1-0/+24
*', to 'str', i.e., Python string. llvm-svn: 134543
2011-07-03Add a CLEANUP_DOCSTRING state to our FSM to do cleanup of the Python docstringsJohnny Chen1-16/+41
generated from the swig docstring features instead of blindly applying the cleanup action for all input lines. llvm-svn: 134368
2011-07-03Add swig docstrings for SBFrame.h.Johnny Chen1-2/+3
Add post-processing step to remove the trailing blank lines from the docstrings of lldb.py. llvm-svn: 134360
2011-07-02Refine the post-processing phase of lldb.py to remove some more ↵Johnny Chen1-1/+11
doxygen/c++-comment residues. llvm-svn: 134326
2011-07-01Add some documentation blocks to SBTarget.h and use swig docstring feature toJohnny Chen1-0/+16
take advantage of them. Update modify-python-lldb.py to remove some 'residues' resulting from swigification. llvm-svn: 134269
2011-06-14Generalise pattern for matching IsValid signaturePeter Collingbourne1-1/+1
Previously the IsValid pattern matched only function signatures of the form: def IsValid(*args): ... However under SWIG 1.3.40 on Linux the signature reads: def IsValid(self): ... The new pattern matches both signature types by matching only up to the left paren. llvm-svn: 132968