| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
All the code required to generate the language bindings for Python and
Lua lives under scripts, even though the majority of this code aren't
scripts at all, and surrounded by scripts that are totally unrelated.
I've reorganized these files and moved everything related to the
language bindings into a new top-level directory named bindings. This
makes the corresponding files self contained and much more discoverable.
Differential revision: https://reviews.llvm.org/D72437
|
| |
|
|
|
|
|
|
|
|
|
| |
The current SWIG extensions for the string conversion operator is Python
specific because it uses the PythonObjects. This means that the code
cannot be reused for other SWIG supported languages such as Lua.
This reimplements the extensions in a more generic way that can be
reused. It uses a SWIG macro to reduce code duplication.
Differential revision: https://reviews.llvm.org/D72377
|
| |
|
|
|
|
| |
Guard the embedded Python code in LLDB's interface files by the
SWIGPYTHON define to ensures they can be reused for other languages
supported by SWIG.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This reverts commit f9b91a52797325ccaaee229e414beae7c03f1948.
llvm-svn: 364951
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch teaches lldb to detect when there are missing frames in a
backtrace due to a sequence of tail calls, and to fill in the backtrace
with artificial tail call frames when this happens. This is only done
when the execution history can be determined from the call graph and
from the return PC addresses of calls on the stack. Ambiguous sequences
of tail calls (e.g anything involving tail calls and recursion) are
detected and ignored.
Depends on D49887.
Differential Revision: https://reviews.llvm.org/D50478
llvm-svn: 343900
|
| |
|
|
|
|
| |
<rdar://problem/31411646>
llvm-svn: 300012
|
| |
|
|
|
|
|
|
|
|
| |
This API is currently a no-op (in the sense that it has the same behavior as the already existing GetName()), but is meant long-term to provide a best-for-visualization version of the name of a function
It is still not hooked up to the command line 'bt' command, nor to the 'gui' mode, but I do have ideas on how to make that work going forward
rdar://21203242
llvm-svn: 241482
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D10711
llvm-svn: 240660
|
| |
|
|
|
|
| |
const.".
llvm-svn: 240565
|
| |
|
|
| |
llvm-svn: 240435
|
| |
|
|
|
|
| |
access to the caller frame of the current frame
llvm-svn: 239853
|
| |
|
|
| |
llvm-svn: 238395
|
| |
|
|
|
|
|
|
|
|
| |
lldb::addr_t SBFrame::GetCFA();
This gets the CFA (call frame address) of the frame so it allows us to take an address that is on the stack and figure out which thread it comes from.
Also modified the heap.py module to be able to find out which variable in a frame's stack frame contains an address. This way when ptr_refs finds a match on the stack, it get then report which variable contains the pointer.
llvm-svn: 238393
|
|
|
Summary:
Move scripts/Python/interface to scripts/interface so that we
can start making iterative improvements towards sharing the
interface files between multiple languages (each of which would
have their own directory as now).
Test Plan: Build and see.
Reviewers: zturner, emaste, clayborg
Reviewed By: clayborg
Subscribers: mjsabby, lldb-commits
Differential Revision: http://reviews.llvm.org/D9212
llvm-svn: 235676
|
