Commit Graph

61 Commits

Author SHA1 Message Date
Pavel Labath e090389c4a modify-python-lldb.py: (Re)move __len__ and __iter__ support
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-04 10:13:59 +00:00
Pavel Labath 4da5a1dbab modify-python-lldb.py: clean up __iter__ and __len__ support
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-03 11:48:38 +00:00
Pavel Labath 4bc0500635 Make operator==s consistent between c++ and python APIs
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-04-02 10:18:46 +00:00
Pavel Labath 01b595c0cb Fix/unify SBType comparison
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-13 13:45:14 +00:00
Pavel Labath 7f5237bccc Add "operator bool" to SB APIs
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-03-11 13:58:46 +00:00
Pavel Labath 11bc3f49da Insert blocks of python code with swig instead of modify-python-lldb.py
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-27 14:16:48 +00:00
Pavel Labath 8d6b60c14c Embed swig version into lldb.py in a different way
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
2019-02-15 07:41:12 +00:00
Kate Stone b9c1b51e45 *** This commit represents a complete reformatting of the LLDB source code
*** 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
2016-09-06 20:57:50 +00:00
Zachary Turner eddf19f995 Insert the SWIG version into LLDB's __init__.py
The goal here is to allow us to add skip / xfail decorators
based on SWIG version.

llvm-svn: 253262
2015-11-16 22:40:20 +00:00
Zachary Turner 37a0fc483b Remove a debug print statement.
llvm-svn: 252384
2015-11-07 01:12:53 +00:00
Zachary Turner c22811bbcc Python 3 - Use __bool__() instead of __nonzero__() for truthiness.
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-07 01:08:25 +00:00
Bruce Mitchener a18231a5e9 [swig] Start of pylint on python build scripts.
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-11-05 23:57:33 +00:00
Zachary Turner 6532c6a1e7 Update swig generation scripts to support Python 3.
llvm-svn: 249467
2015-10-06 21:11:28 +00:00
Greg Clayton bc41bf70bd Make sure that the lldb globals:
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-12-10 19:18:23 +00:00
Filipe Cabecinhas c281a3bf43 Makefile patches from Charles Davis and Daniel Malea (+ one or two tweaks).
llvm-svn: 167242
2012-11-01 18:55:16 +00:00
Johnny Chen 1b72f09150 Export the APIs submitted by Dawn to the Python bindings. Add a simple test case for the SBModule.compile_unit_iter() API.
llvm-svn: 152952
2012-03-16 21:55:42 +00:00
Johnny Chen 1738fad337 Add a missing ')' in the comment.
llvm-svn: 144145
2011-11-08 23:08:03 +00:00
Johnny Chen 01a678603a SBValue::Watch() and SBValue::WatchPointee() are now the official API for 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-14 00:42:25 +00:00
Greg Clayton 1b282f9619 Cleaned up the SBWatchpoint public API.
llvm-svn: 141876
2011-10-13 18:08:26 +00:00
Johnny Chen fdce6dc19d Add comment markers for in_range(symbol, section).
llvm-svn: 141033
2011-10-03 21:48:40 +00:00
Johnny Chen 97b5083cd6 Add docstring to in_range() function residing in the lldb module.
llvm-svn: 140833
2011-09-30 00:49:02 +00:00
Johnny Chen c44e20cec0 Migrate the in_range(symbol, section) and symbol_iter(module, section) 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-30 00:42:49 +00:00
Johnny Chen 9d954d8665 Add SBTarget::GetLastCreatedWatchpointLocation() API and export to the 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-27 20:29:45 +00:00
Johnny Chen d4dd7993b5 Export the watchpoint related API (SBWatchpointLocation class and added 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-27 01:19:20 +00:00
Johnny Chen 5b94dc28b3 SBSection supports iteration through its subsections, represented as 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-09-24 04:51:43 +00:00