This test exposed a very long standing issue that the python file
objects returned by the FILE* typemap were unusable on non-darwin
platforms. The reason they work on darwin is that they rely on a
non-standard extension to fetch the "mode" of a FILE* object. On other
platforms, this code was #ifdefed out, and so we were returning an empty
mode.
As there's no portable way to get this information, I just change the
non-darwin path to return "r+", which should permit both reading and
writing operations on the object. If the underlying file descriptor
turns out to be incompatible with this mode, the operating system should
return EBADF (or equivalent), instead of the "file not open for XXX"
error from python.
llvm-svn: 373573
Summary:
This patch factors out File as an abstract base
class and moves most of its actual functionality into
a subclass called NativeFile. In the next patch,
I'm going to be adding subclasses of File that
don't necessarily have any connection to actual OS files,
so they will not inherit from NativeFile.
This patch was split out as a prerequisite for
https://reviews.llvm.org/D68188
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68317
llvm-svn: 373564
Summary:
Add new methods to SBDebugger to set IO files as SBFiles instead of
as FILE* streams.
In future commits, the FILE* methods will be deprecated and these
will become the primary way to set the debugger I/O streams.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68181
llvm-svn: 373563
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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:
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
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
As per the discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20190218/048007.html
This commit implements option (3):
> Go back to initializing the reproducer before the rest of the debugger.
> The method wouldn't be instrumented and guarantee no other SB methods are
> called or SB objects are constructed. The initialization then becomes part
> of the replay.
Differential revision: https://reviews.llvm.org/D58410
llvm-svn: 354631
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
The loop searching for use_lldb_suite_root had a bug where if the marker
file happened to be missing, it would enter an infinite loop. While this
shouldn't happen in normal circumstances, it can happen accidentally,
and debugging it is not very pleasant.
The loop had an exit condition, but it was incorrent (os.path.dirname
returning None). This will never happen as dirname will just return the
same folder over and over again once it reaches the root folder. This
fixes the exit condition to account for that.
llvm-svn: 353406
Summary:
This patch adds support of expression evaluation in a context of some object.
Consider the following example:
```
struct S {
int a = 11;
int b = 12;
};
int main() {
S s;
int a = 1;
int b = 2;
// We have stopped here
return 0;
}
```
This patch allows to do something like that:
```
lldb.frame.FindVariable("s").EvaluateExpression("a + b")
```
and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be
used (not locals `a` and `b`).
This is achieved by replacing of `this` type and object for the expression. This
has some limitations: an expression can be evaluated only for values located in
the debuggee process memory (they must have an address of `eAddressTypeLoad`
type).
Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille
Reviewed By: jingham
Subscribers: abidh, lldb-commits, leonid.mashinskiy
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D55318
llvm-svn: 353149
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
Summary:
Simplify SWIG invocation and handling of generated files.
The `swig_wrapper` target can generate `LLDBWrapPython.cpp` and `lldb.py` in its own binary directory, so we can get rid of a few global variables and their logic. We can use the swig_wrapper's BINARY_DIR target property to refer to it and liblldb's LIBRARY_OUTPUT_DIRECTORY to refer to the framework/shared object output directory.
Reviewers: JDevlieghere, aprantl, stella.stamenova, beanz, zturner, xiaobai
Reviewed By: aprantl
Subscribers: mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55332
llvm-svn: 350393
This builds on https://reviews.llvm.org/D43884 and https://reviews.llvm.org/D43886 and extends LLDB support of Obj-C exceptions to also look for a "current exception" for a thread in the C++ exception handling runtime metadata (via call to __cxa_current_exception_type). We also construct an actual historical SBThread/ThreadSP that contains frames from the backtrace in the Obj-C exception object.
The high level goal this achieves is that when we're already crashed (because an unhandled exception occurred), we can still access the exception object and retrieve the backtrace from the throw point. In Obj-C, this is particularly useful because a catch+rethrow is very common and in those cases you currently don't have any access to the throw point backtrace.
Differential Revision: https://reviews.llvm.org/D44072
llvm-svn: 349718
This patch changes the way the reproducer is initialized. Rather than
making changes at run time we now do everything at initialization time.
To make this happen we had to introduce initializer options and their SB
variant. This allows us to tell the initializer that we're running in
reproducer capture/replay mode.
Because of this change we also had to alter our testing strategy. We
cannot reinitialize LLDB when using the dotest infrastructure. Instead
we use lit and invoke two instances of the driver.
Another consequence is that we can no longer enable capture or replay
through commands. This was bound to go away form the beginning, but I
had something in mind where you could enable/disable specific providers.
However this seems like it adds very little value right now so the
corresponding commands were removed.
Finally this change also means you now have to control this through the
driver, for which I replaced --reproducer with --capture and --replay to
differentiate between the two modes.
Differential revision: https://reviews.llvm.org/D55038
llvm-svn: 348152
Summary:
This patch fixes the next situation. On Windows clang-cl makes no stub before
the main function, so the main function is located exactly on module entry
point. May be it is the same on other platforms. So consider the following
sequence:
- set a breakpoint on main and stop there;
- try to evaluate expression, which requires a code execution on the debuggee
side. Such an execution always returns to the module entry, and the plan waits
for it there;
- the plan understands that it is complete now and removes its breakpoint. But
the breakpoint site is still there, because we also have a breakpoint on
entry;
- StopInfo analyzes a situation. It sees that we have stopped on the breakpoint
site, and it sees that the breakpoint site has owners, and no one logical
breakpoint is internal (because the plan is already completed and it have
removed its breakpoint);
- StopInfo thinks that it's a user breakpoint and skips it to avoid recursive
computations;
- the program continues.
So in this situation the program continues without a stop right after
the expression evaluation. To avoid this an additional check that
the plan was completed was added.
Reviewers: jingham, zturner, boris.ulasevich
Reviewed by: jingham
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53761
llvm-svn: 347974
When I landed the initial reproducer framework I knew there were some
things that needed improvement. Rather than bundling it with a patch
that adds more functionality I split it off into this patch. I also
think the API is stable enough to add unit testing, which is included in
this patch as well.
Other improvements include:
- Refactor how we initialize the loader and generator.
- Improve naming consistency: capture and replay seems the least ambiguous.
- Index providers by name and make sure there's only one of each.
- Add convenience methods for creating and accessing providers.
Differential revision: https://reviews.llvm.org/D54616
llvm-svn: 347716
When debugging read-only memory we cannot use software breakpoint. We
already have support for hardware breakpoints and users can specify them
with `-H`. However, there's no option to force LLDB to use hardware
breakpoints internally, for example while stepping.
This patch adds a setting target.require-hardware-breakpoint that forces
LLDB to always use hardware breakpoints. Because hardware breakpoints
are a limited resource and can fail to resolve, this patch also extends
error handling in thread plans, where breakpoints are used for stepping.
Differential revision: https://reviews.llvm.org/D54221
llvm-svn: 346920
Summary:
There are 2 changes here:
1. Use system sed instead of the sed found in the user's path. This
fixes this script in the case the user has gnu-sed in their $PATH before
bsd sed since `-i ''` isn't compatible and you need `-i` instead.
2. `set -e` in this script so it fails as soon as one of these commands
fail instead of throwing errors for each file if they fail
Since this is only ran on macOS, and we're already using this
absolute path below, this seems like a safe addition
Reviewers: kastiglione, beanz
Reviewed By: kastiglione
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D49776
llvm-svn: 346099
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
Fix llvm.org/pr39054:
- Register _lldb as a built-in module during initialization of script interpreter,
- Reverse the order of imports in __init__.py: first try to import by absolute name, which will find the built-in module in the context of lldb (and other hosts that embed liblldb), then try relative import, in case the module is being imported from Python interpreter.
This works for SWIG>=3.0.11; before that, SWIG did not support custom module import code.
Differential revision: https://reviews.llvm.org/D52404
llvm-svn: 344474
LC_BUILD_VERSION load command handling - this
commit is a combination of patches by Adrian
Prantl and myself. llvm::Triple::BridgeOS
isn't defined yet, so all references to that
are currently commented out.
Also update Xcode project file to build the
NativePDB etc plugins.
<rdar://problem/43353615>
llvm-svn: 344209
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
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:
This patch adds a framework for adding descriptions to the command completions we provide.
It also adds descriptions for completed top-level commands so that we can test this code.
Completions are in general supposed to be displayed alongside the completion itself. The descriptions
can be used to provide additional information about the completion to the user. Examples for descriptions
are function signatures when completing function calls in the expression command or the binary name
when providing completion for a symbol.
There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective
APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be
used), so that's why I still had to change some function signatures. Also, as the old API only passes around a
list of matches, and the descriptions are for these functions just another list, I had to add some code that
essentially just ensures that both lists are always the same side (e.g. all the manual calls to
`descriptions->AddString(X)` below a `matches->AddString(Y)` call).
The initial command descriptions that come with this patch are just reusing the existing
short help that is already added in LLDB.
An example completion with descriptions looks like this:
```
(lldb) pl
Available completions:
platform -- Commands to manage and create platforms.
plugin -- Commands for managing LLDB plugins.
```
Reviewers: #lldb, jingham
Reviewed By: #lldb, jingham
Subscribers: jingham, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D51175
llvm-svn: 342181
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
This patch extends the SBAPI to allow for setting a breakpoint not
only at a specific line, but also at a specific (minimum) column. When
a column is specified, it will try to find an exact match or the
closest match on the same line that comes after the specified
location.
Differential Revision: https://reviews.llvm.org/D51461
llvm-svn: 341078
GNU sed and BSD sed have a different command-line syntax for in-place
editing, and the current form of the script would only work with BSD
sed. The easiest way to get cross-platform behavior is to specify a
backup suffix and then just delete the backup file at the end. (BSD sed
is the default on macOS, but it's possible to acquire GNU coreutils and
have your `sed` be GNU sed even on macOS; I'm aware it's not officially
supported in any capacity, but it's easy enough to support here.)
An alternative would be using `perl -p -i -e` instead of `sed -i`, but I
figured it was best to make the minimal working change.
Differential Revision: https://reviews.llvm.org/D51374
llvm-svn: 340885
Summary:
The new API appends an image search path to the
target's path mapping list.
Reviewers: aprantl, clayborg, labath
Reviewed By: aprantl
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D49739
llvm-svn: 339175
This reverts r338154. This change is actually unnecessary, as the CMake
bug I referred to was actually not a bug but a misunderstanding of
CMake.
Original Differential Revision: https://reviews.llvm.org/D49888
llvm-svn: 338178
Summary:
This patch adds the possibility to specify an exit code when calling quit.
We accept any int, even though it depends on the user what happens if the int is
out of the range of what the operating system supports as exit codes.
Fixes rdar://problem/38452312
Reviewers: davide, jingham, clayborg
Reviewed By: jingham
Subscribers: clayborg, jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D48659
llvm-svn: 336824
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
Haibo Huang