| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
A Previous patch added support for creating VarDecls for global
variables. This patch updates this test to be more strict and
actually check these, not just the types.
llvm-svn: 350242
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were several problems preventing this from working. The
first is that when the PDB had an absolute path to the main
source file, we would construct an invalid path by prepending the
compilation directory to it anyway. So we needed to check if the
path is already absolute first.
Second, LLDB assumes that the zero'th item in the support file list
is the main compilation unit. We were respecting this requirement,
but LLDB *also* requires that file to appear somewhere in the list
starting from index 1 as well. So the main compilation file should
appear in the support file list twice. And when parsing a line
table, it expects the LineEntry records to be constructed using
the 1-based index. With these two fixes we can now set breakpoints
by file and line using the native PDB reader.
llvm-svn: 350240
|
|
|
|
|
|
|
|
| |
The warning comes from the fact that the MOCK_METHOD macros don't use the
override keyword internally. This makes us not use it in the manually overriden
methods either, to be consistent.
llvm-svn: 350209
|
|
|
|
| |
llvm-svn: 350177
|
|
|
|
|
|
|
|
| |
Simplify some code in PreprocessCommand. This change improves
consistency, reduces the indentation and makes the code easier to follow
overall.
llvm-svn: 350166
|
|
|
|
| |
llvm-svn: 350164
|
|
|
|
| |
llvm-svn: 350163
|
|
|
|
|
|
| |
The quoted bug report (llvm.org/PR20270) was closed in 2014.
llvm-svn: 350160
|
|
|
|
| |
llvm-svn: 350149
|
|
|
|
| |
llvm-svn: 350148
|
|
|
|
| |
llvm-svn: 350147
|
|
|
|
|
|
| |
And probably, less error prone. NFCI.
llvm-svn: 350146
|
|
|
|
| |
llvm-svn: 350122
|
|
|
|
| |
llvm-svn: 350121
|
|
|
|
| |
llvm-svn: 350094
|
|
|
|
|
|
|
|
| |
python 3.7 removes re._pattern_type. Fix the one place where we were
depending on the type of regular expressions to compute the type
dynamically.
llvm-svn: 350093
|
|
|
|
|
|
|
|
|
| |
The assertion fired (with a debug visual studio STL) because we tried to
dereference the end of a vector (although it was only to take its
address again and form an end iterator). Rewrite this logic to avoid the
questionable code.
llvm-svn: 350091
|
|
|
|
| |
llvm-svn: 350089
|
|
|
|
|
|
|
| |
This class is unused, and there is already a lldb_private::Range
(defined in lldb/Core/RangeMap.h), which has similar functionality.
llvm-svn: 350088
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Simplify the code by using the contains implementation in IntervalMap.
There is a slight change of behavior here: We now treat an allocation of
size 0, as if it was size 1. This guarantees that the returned addresses
will be unique, whereas previously we would allow the allocation
function to return the same zero-sized region multiple times, as long as
it is not null, and not in the middle of an existing interval (but the
situation when we were placing an larger interval over a zero-sized one
was not detected).
I think this behavior makes more sense, as that is pretty much the same
guarantee as offered by malloc (except that is permitted to also return
nullptr).
Reviewers: vsk
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55761
llvm-svn: 350087
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
r346165 introduced a bug, where we would fail to parse the size of an
array if that size happened to match an existing die offset.
The logic was:
if (DWARFDIE count = die.GetReferencedDie(DW_AT_count))
num_elements = compute_vla_size(count);
else
num_elements = die.GetUsigned(DW_AT_count); // a fixed-size array
The problem with this logic was that GetReferencedDie did not take the
form class of the attribute into account, and would happily return a die
reference for any form, if its value happened to match some die.
As this behavior is inconsistent with how llvm's DWARFFormValue class
operates, I chose to fix the problem by making our version of this class
match the llvm behavior. For this to work, I had to add an explicit form
class check to the .apple_XXX tables parsing code, because they do
(incorrectly?) use data forms as die references.
Reviewers: aprantl, clayborg
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D55991
llvm-svn: 350086
|
|
|
|
|
|
|
|
| |
struct/union' on Windows
This warning comes up in the ObjC language plugin because of the use of nameless structs. This change suppresses the warning.
llvm-svn: 349977
|
|
|
|
|
|
|
|
| |
Using compare is verbose, bug prone and potentially inefficient (because
of early termination). Replace relevant call sites with the (in)equality
operator.
llvm-svn: 349972
|
|
|
|
| |
llvm-svn: 349971
|
|
|
|
|
|
|
|
|
|
| |
Summary: Adding some test coverage while I'm around.
Reviewers: JDevlieghere, aprantl, zturner, clayborg, jingham
Differential Revision: https://reviews.llvm.org/D56017
llvm-svn: 349970
|
|
|
|
|
|
|
| |
We already know the final size here so we might as well reserve it so we
don't have to re-allocate during the loop.
llvm-svn: 349967
|
|
|
|
|
|
| |
Skip a number of tests on Windows that are flakey and will pass/fail unexpectedly every dozen or so runs.
llvm-svn: 349946
|
|
|
|
|
|
| |
Prior to this there were 3 places that were duplicating the logic to detect if a section can/should be loaded and some were doing things a bit differently. Now it is all centralized in one place and it is done correctly.
llvm-svn: 349926
|
|
|
|
|
|
|
|
|
| |
They both run the same command, and people get used to typing the shortest
string they can, so we should support alias info on shortened strings as well.
<rdar://problem/46859207>
llvm-svn: 349874
|
|
|
|
|
|
| |
This fixes the second call at line 640 that I missed in r349858.
llvm-svn: 349869
|
|
|
|
| |
llvm-svn: 349865
|
|
|
|
| |
llvm-svn: 349864
|
|
|
|
| |
llvm-svn: 349861
|
|
|
|
|
|
|
| |
Found by the address sanitizer on GreenDragon:
http://green.lab.llvm.org/green/view/LLDB/job/lldb-sanitized/1628/console
llvm-svn: 349858
|
|
|
|
|
|
|
|
| |
recognized arguments by default
Differential Revision: https://reviews.llvm.org/D55954
llvm-svn: 349856
|
|
|
|
|
|
|
|
|
|
| |
Previously we would create these for local variables but not for
global variables.
Also updated existing tests which created global variables to check
for them in the resulting AST.
llvm-svn: 349854
|
|
|
|
|
|
|
|
| |
These are tests that found actual, but hard to fix, bugs that are
tracked elsewhere. Leaving them red only distracts from new failures
this bot finds.
llvm-svn: 349851
|
|
|
|
|
|
|
| |
Removes redundant calls to ::get() from smart pointers in the source/API
directory..
llvm-svn: 349821
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unexpected successes should be considered failures because they can hide
regressions when not addressed. When a test is fixed and not re-enabled,
it can easily regress without us noticing.
I couldn't find a good way to make this change other than changing it in
the unittest2 framework. I know this is less than optimal but since we
have the dependency checked in and the change is pretty fundamental to
the framework I think it's not unreasonable.
Differential revision: https://reviews.llvm.org/D55835
llvm-svn: 349818
|
|
|
|
|
|
| |
Several of the tests are now passing. This change is enabling them.
llvm-svn: 349813
|
|
|
|
|
|
|
| |
This test is now marked as unsupported on Windows - it is not technically "unsupported" on Windows, but it fails because "expr ptr" does not evaluate correctly. However, the error message contains the expected string, so the test "passes" despite the fact that the commands failed
The following bug has been opened for it: llvm.org/pr40119
llvm-svn: 349784
|
|
|
|
|
|
| |
Both of these are now passing. I've resolved the bugs as well for verification.
llvm-svn: 349783
|
|
|
|
|
|
| |
There are a couple of tests in TestEvents that are now passing.
llvm-svn: 349781
|
|
|
|
|
|
| |
The test is "passing" on windows, but it is a false positive. Skip it on Windows until it is fixed on all platforms.
llvm-svn: 349775
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D55841
llvm-svn: 349767
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D55472
llvm-svn: 349766
|
|
|
|
| |
llvm-svn: 349722
|
|
|
|
| |
llvm-svn: 349721
|
|
|
|
|
|
| |
This is a set of tests that were all marked as failing becuse of pr24764. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349719
|
|
|
|
|
|
|
|
|
|
|
|
| |
__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
|