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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345693
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345686
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345678
This change allows you to write a new breakpoint type where the
logic for setting breakpoints is determined by a Python callback
written using the SB API's.
Differential Revision: https://reviews.llvm.org/D51830
llvm-svn: 342185
Summary:
Swig wraps C++ code into SWIG_PYTHON_THREAD_BEGIN_ALLOW; ... SWIG_PYTHON_THREAD_END_ALLOW;
Thus, LLDB crashes with "Fatal Python error: Python memory allocator called without holding the GIL" when calls an lldb_SB***___str__ function.
Reviewers: clayborg
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D51569
llvm-svn: 341482
Summary:
This change fixes one issue with `lldb.command`, and also reduces the implementation.
The fix: a command function's docstring was not shown when running `help <command_name>`. This is because the docstring attached the source function is not propagated to the decorated function (`f.__call__`). By returning the original function, the docstring will be properly displayed by `help`.
Also with this change, the command name is assumed to be the function's name, but can still be explicitly defined as previously.
Additionally, the implementation was updated to:
* Remove inner class
* Remove use of `inspect` module
* Remove `*args` and `**kwargs`
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: keith, xiaobai, lldb-commits
Differential Revision: https://reviews.llvm.org/D48658
llvm-svn: 336287
Use proper cmake techniques to detect where the libedit package resides.
This allows for the use of libedit from an alternative location which is
needed for supporting cross-compilation.
llvm-svn: 333041
an empty Python string object when it reads a 0-length
string out of memory (and a successful SBError object).
<rdar://problem/26186692>
llvm-svn: 321338
When introduced, breakpoint names were just tags that you could
apply to breakpoints that would allow you to refer to a breakpoint
when you couldn't capture the ID, or to refer to a collection of
breakpoints.
This change makes the names independent holders of breakpoint options
that you can then apply to breakpoints when you add the name to the
breakpoint. It adds the "breakpoint name configure" command to set
up or reconfigure breakpoint names. There is also full support for
then in the SB API, including a new SBBreakpointName class.
The connection between the name and the breakpoints
sharing the name remains live, so if you reconfigure the name, all the
breakpoint options all change as well. This allows a quick way
to share complex breakpoint behavior among a bunch of breakpoints, and
a convenient way to iterate on the set.
You can also create a name from a breakpoint, allowing a quick way
to copy options from one breakpoint to another.
I also added the ability to make hidden and delete/disable protected
names. When applied to a breakpoint, you will only be able to list,
delete or disable that breakpoint if you refer to it explicitly by ID.
This feature will allow GUI's that need to use breakpoints for their
own purposes to keep their breakpoints from getting accidentally
disabled or deleted.
<rdar://problem/22094452>
llvm-svn: 313292
PyObject_CallFunction returns a PyObject which needs to be
decref'ed when it is no longer needed.
Patch by David Luyer
Differential Revision: https://reviews.llvm.org/D33740
llvm-svn: 305873
Summary:
The current version of LLDB installs six.py into global python library directory. This approach produces conflicts downstream with distribution's py-six copy.
Introduce new configure option LLDB_USE_SYSTEM_SIX (disabled by default). Once specified as TRUE, six.py won't be installed to Python's directory.
Add new option in finishSwigWrapperClasses.py, namely --useSystemSix.
Sponsored by <The NetBSD Foundation>
Reviewers: mgorny, emaste, clayborg, joerg, labath
Reviewed By: labath
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29405
llvm-svn: 294071
A combination of broken escaping in CMake and in the python swig
generation scripts meant that the swig generation step would fail
whenever there were spaces or special characters in parameters passed to
swig.
The fix for this in CMakeLists is to use the VERBATIM option on all
COMMAND-based custom builders relying on CMake to properly escape each
argument in the generated file.
Within the python swig scripts, the fix is to call subprocess.Popen with
a list of raw argument strings rather than ones that are incorrectly
manually escaped, then passed to a shell subprocess via
subprocess.Popen(' '.join(params)). This also prevents nasty things
happening such as accidental command-injection.
This allows us to have the swig / python executables in paths containing
special chars and spaces, (or on shared storage on Win32, e.g
\\some\path or C:\Program Files\swig\swig.exe).
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D26757
llvm-svn: 289956
Rationale:
scripts/Python/modules: android is excluded at a higher level, so no point in
checking here
tools/lldb-mi: lldb-mi builds fine (with some cosmetic tweaks) on android, and
there is no reason it shouldn't.
tools/lldb-server: LLDB_DISABLE_LIBEDIT/CURSES already take the platform into
account, so there is no point in checking again.
I am reasonably confident this should not break the build on any platform, but
I'll keep an eye out on the bots.
llvm-svn: 288661
Summary: This tool is only built on Darwin, and the name darwin-debug matches the Xcode project. We should have this in sync unless there is a good reason not to.
Reviewers: zturner, tfiala, labath
Subscribers: labath, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D25745
llvm-svn: 285356
Summary:
If Python is installed to a location that contains spaces
(e.g. "C:\Program Files\Python3") then the build fails while attempting
to run the modify-python-lldb.py script because the path to the Python
executable is not double-quoted before being passed to the shell. The
fix consists of letting Python handle the formatting of the command
line, since subprocess.Popen() is perfectly capable of handling paths
containing spaces if it's given the command and arguments as a list
instead of a single pre-formatted string.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D25396
llvm-svn: 284100
Jim Ingham