Commit Graph

980 Commits

Author SHA1 Message Date
Stefan Granitz 7e6f355b3e [lldb] Remove Xcode project legacy
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
2019-07-24 09:20:14 +00:00
Jonas Devlieghere 63b921f01d Remove Xcode project remnants
llvm-svn: 366745
2019-07-22 21:51:04 +00:00
Jonas Devlieghere d0ad1bc328 [LLDB] Remove the Xcode project
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
2019-07-22 21:20:23 +00:00
Jordan Rupprecht 301c65a8e0 [lldb][swig] Fix autodocs flag parsing
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
2019-07-18 18:18:51 +00:00
Jonas Devlieghere 0c2cd67425 [swig] Enable autodoc feature
This patch enables the SWIG `autodoc` feature so that the generated
Python reference [1] includes class properties.

[1] https://lldb.llvm.org/python_reference/index.html

llvm-svn: 366471
2019-07-18 17:40:30 +00:00
Jonas Devlieghere 63a0c2bce8 Revert "[swig] Add workaround for old swig"
With the deprecation of swig 1.x (r366213), this workaround should no
longer be necessary.

llvm-svn: 366221
2019-07-16 15:54:33 +00:00
Jonas Devlieghere d3941e6630 [SWIG] Deprecate SWIG 1.x
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
2019-07-16 15:14:01 +00:00
Jonas Devlieghere 597dc0061f [swig] Add workaround for old swig
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
2019-07-11 00:12:59 +00:00
Davide Italiano 89ed2e0a0a [scripts] Remove the unused 'shush' script.
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
2019-07-10 18:13:46 +00:00
Jonas Devlieghere 89b658428b [swig] Don't mess with swig internals.
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
2019-07-02 22:18:35 +00:00
Jonas Devlieghere 97316fff5d Revert "[swig] Define attribute(ref) instead of accessing swig internals."
This reverts commit f9b91a5279.

llvm-svn: 364951
2019-07-02 18:04:55 +00:00
Jonas Devlieghere f9b91a5279 [swig] Define attribute(ref) instead of accessing swig internals.
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
2019-07-02 17:25:20 +00:00
Jim Ingham 7d7b788fb1 Make SBDebugger.RunCommandInterpreter callable from Python.
Authored by: Lukas Boger

Differential Revision: https://reviews.llvm.org/D61602

llvm-svn: 360730
2019-05-15 00:08:55 +00:00
Pavel Labath f96b6d9270 Kill modify-python-lldb.py
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-24 13:23:19 +00:00
Pavel Labath 330bc8af13 modify-python-lldb: Remove \a-removing code
instead, remove \a directly from the interface files.

llvm-svn: 358967
2019-04-23 10:04:22 +00:00
Pavel Labath 27e9d982eb modify-python-lldb.py: Remove docstring formatting code
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-21 12:48:53 +00:00
Pavel Labath eba97426d4 Clean up docstrings in swig interface files
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
2019-04-18 16:23:33 +00:00
Jonas Devlieghere ea6037d84e [Shell] Simplify Extracting Python Version
Instead of parsing the Python version with a fairly convoluted regex,
just print the major and minor version and call it a day.

llvm-svn: 358635
2019-04-18 01:37:19 +00:00
Pavel Labath f5f45f21d8 Docstringify some comments in the swig interface files
Without these, the comments don't end up in the generated python code.

llvm-svn: 358055
2019-04-10 07:55:04 +00:00
Pavel Labath 26ca5a57bc Remove unneeded #ifdef SWIGs
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
2019-04-09 09:03:43 +00:00
Pavel Labath f2348c88f1 modify-python-lldb.py: Remove ifdef SWIG-removing code
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-08 08:43:07 +00:00
Pavel Labath 78a514bf9d modify-python-lldb.py: Insert initialization code with swig instead
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-05 09:56:55 +00:00
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
Jonas Devlieghere ae1cc995e3 [Cmake] Unify python variables
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
2019-03-29 17:35:42 +00:00
Jonas Devlieghere 903a9c74f0 [Python] Remove readline module
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
2019-03-29 17:12:08 +00:00
Jim Ingham 43aaafc0e1 Fix the swig typemap for "uint32_t *versions, uint32_t num_versions".
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
2019-03-28 19:25:54 +00:00
Serge Guelton 1a12dd70c0 python 2/3 compat: commands vs subprocess
Differential Revision: https://reviews.llvm.org/D59584

llvm-svn: 356995
2019-03-26 14:46:15 +00:00
Serge Guelton 525cd59f5a Python 2/3 compatibility: from __future__ import print_function
Differential Revision: https://reviews.llvm.org/D59580

llvm-svn: 356695
2019-03-21 18:27:40 +00:00
Serge Guelton 468219b387 Workaround Python's map difference between Python2/3
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
2019-03-21 14:44:58 +00:00
Serge Guelton 32cffcf1ab Use list comprehension instead of map/filter to prepare Python2/3 compat
Differential Revision: https://reviews.llvm.org/D59579

llvm-svn: 356647
2019-03-21 07:19:09 +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
Shoaib Meenai 5be71faf4b [build] Rename clang-headers to clang-resource-headers
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
2019-03-04 21:19:53 +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
Jonas Devlieghere 936c62422f [Reproducers] Initialize reproducers before initializing the debugger.
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
2019-02-21 22:26:16 +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
Pavel Labath 67f6d842fa use_lldb_suite.py: Fix potential infinite loop
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
2019-02-07 14:03:43 +00:00
Aleksandr Urakov 40624a085c [Expressions] Add support of expressions evaluation in some object's context
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
2019-02-05 09:14:36 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
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
2019-01-19 08:50:56 +00:00
Davide Italiano 8c2fe4797c [Python] Update PyString_FromString() to work for python 2 and 3.
Reviewers: aprantl, JDevlieghere, friss, zturner

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D56511

llvm-svn: 350769
2019-01-09 22:52:47 +00:00
Stefan Granitz f9ef9e0c19 [CMake] Python bindings generation polishing
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
2019-01-04 12:47:02 +00:00
Kuba Mracek 4c7f5d5c5a [lldb] Add a "display-recognized-arguments" target setting to show recognized arguments by default
Differential Revision: https://reviews.llvm.org/D55954

llvm-svn: 349856
2018-12-20 23:38:19 +00:00
Tatyana Krasnukha 92e5e36004 Overload GetMemoryRegions for the ProcessMinidump
Differential Revision: https://reviews.llvm.org/D55841

llvm-svn: 349767
2018-12-20 15:05:43 +00:00
Kuba Mracek c9e1190a27 [lldb] Retrieve currently handled Obj-C exception via __cxa_current_exception_type and add GetCurrentExceptionBacktrace SB ABI
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
2018-12-20 02:01:59 +00:00
Pavel Labath a1ff820992 Make scripts/analyzer-project-deps compatible with python3
llvm-svn: 348479
2018-12-06 10:27:38 +00:00
Jonas Devlieghere 15eacd741f [Reproducers] Change how reproducers are initialized.
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
2018-12-03 17:28:29 +00:00
Aleksandr Urakov 9b087d2ce6 [Target] Do not skip a stop on a breakpoint if a plan was completed
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
2018-11-30 09:45:52 +00:00
Jonas Devlieghere 68ed93d252 [Reproducers] Improve reproducer API and add unit tests.
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
2018-11-27 22:11:02 +00:00