| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
The new LLVM header is one line shorter than the old one, which lead to
some test failures. Ideally tests should rely on line numbers for
breakpoints or output, but that's a different discussion. Hopefully this
turns the bots green again.
llvm-svn: 351779
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/677/steps/test/logs/stdio
llvm-svn: 351385
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the behavior when printing C++ function references:
where we previously would get a <could not determine size>, there is
now a <no summary available>. It's not clear to me whether this is a
bug or an omission, but it's one step further than LLDB previously
got.
Differential Revision: https://reviews.llvm.org/D56798
llvm-svn: 351376
|
|
|
|
|
|
| |
TestNamespaceLookup occasionally passes unexpectedly and TestExitDuringStep occasionally fails unexpectedly
llvm-svn: 351080
|
|
|
|
| |
llvm-svn: 350537
|
|
|
|
|
|
|
|
| |
recognized arguments
Differential Revision: https://reviews.llvm.org/D56027
llvm-svn: 350376
|
|
|
|
|
|
| |
Skip a number of tests on Windows that are flakey and will pass/fail unexpectedly every dozen or so runs.
llvm-svn: 349946
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 349722
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This is a set of tests that were all marked as failing becuse of several different bugs. A couple of the bugs are now resolved as fixed since all the tests that were failing associated with the bug are now 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: 349713
|
|
|
|
|
|
| |
This is a set of tests that were all marked as failing becuse of several different bugs. A couple of the bugs are now resolved as fixed since all the tests that were failing associated with the bug are now 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: 349711
|
|
|
|
|
|
| |
This is a set of tests that were all marked as failing becuse of pr21765. 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: 349668
|
|
|
|
|
|
| |
This is a set of tests that were all marked as failing becuse of pr24489. 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: 349665
|
|
|
|
|
|
|
|
| |
These tests are now passing on linux, at least with top-of-tree clang,
clang-6 and gcc-7.3. It's possible it may still be failing with some
older compilers, but I don't have those around to test.
llvm-svn: 349478
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
objc_exception_throw for Obj-C runtimes
This adds new APIs and a command to deal with exceptions (mostly Obj-C exceptions): SBThread and Thread get GetCurrentException API, which returns an SBValue/ValueObjectSP with the current exception for a thread. "Current" means an exception that is currently being thrown, caught or otherwise processed. In this patch, we only know about the exception when in objc_exception_throw, but subsequent patches will expand this (and add GetCurrentExceptionBacktrace, which will return an SBThread/ThreadSP containing a historical thread backtrace retrieved from the exception object. Currently unimplemented, subsequent patches will implement this).
Extracting the exception from objc_exception_throw is implemented by adding a frame recognizer.
This also add a new sub-command "thread exception", which prints the current exception.
Differential Revision: https://reviews.llvm.org/D43886
llvm-svn: 347813
|
|
|
|
|
|
|
|
| |
An Obj-C array type _NSCallStackArray is used in NSException backtraces. This patch adds a synthetic frontend for _NSCallStackArray, which now correctly returns frame PCs.
Differential Revision: https://reviews.llvm.org/D44081
llvm-svn: 346708
|
|
|
|
|
|
|
|
| |
This patch teaches LLDB about more fields on NSException Obj-C objects, specifically we can now retrieve the "name" and "reason" of an NSException. The goal is to eventually be able to have SB API that can provide details about the currently thrown/caught/processed exception.
Differential Revision: https://reviews.llvm.org/D43884
llvm-svn: 346695
|
|
|
|
|
|
|
|
| |
This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
llvm-svn: 346626
|
|
|
|
| |
llvm-svn: 346186
|
|
|
|
| |
llvm-svn: 346172
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang recently improved its DWARF support for C VLA types. The DWARF
now looks like this:
0x00000051: DW_TAG_variable [4]
DW_AT_location( fbreg -32 )
DW_AT_name( "__vla_expr" )
DW_AT_type( {0x000000d3} ( long unsigned int ) )
DW_AT_artificial( true )
...
0x000000da: DW_TAG_array_type [10] *
DW_AT_type( {0x000000cc} ( int ) )
0x000000df: DW_TAG_subrange_type [11]
DW_AT_type( {0x000000e9} ( __ARRAY_SIZE_TYPE__ ) )
DW_AT_count( {0x00000051} )
Without this patch LLDB will naively interpret the DIE offset 0x51 as
the static size of the array, which is clearly wrong. This patch
extends ValueObject::GetNumChildren to query the dynamic properties of
incomplete array types.
See the testcase for an example:
4 int foo(int a) {
5 int vla[a];
6 for (int i = 0; i < a; ++i)
7 vla[i] = i;
8
-> 9 pause(); // break here
10 return vla[a-1];
11 }
(lldb) fr v vla
(int []) vla = ([0] = 0, [1] = 1, [2] = 2, [3] = 3)
(lldb) quit
rdar://problem/21814005
Differential Revision: https://reviews.llvm.org/D53530
llvm-svn: 346165
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In January Davide sent an e-mail to the mailing list to suggest removing
unmaintained language plugins such as Go and Java. The plan was to have
some cool down period to allow users to speak up, however after that the
plugins were never actually removed.
This patch removes the Go debugger plugin.
The plugin can be added again in the future if it is mature enough both
in terms of testing and maintenance commitment.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html
Differential revision: https://reviews.llvm.org/D54057
llvm-svn: 346157
|
|
|
|
|
|
|
|
| |
Due to some libcxx changes to inlining, this now also crashes,
so it gets reported as "failure" by the bot. This commit doesn't
really change the status quo, just placates the bots.
llvm-svn: 345668
|
|
|
|
|
|
| |
TestStdFunctionStepIntoCallable.py to be unique, NFC
llvm-svn: 344407
|
|
|
|
|
|
|
|
| |
rdar://problem/14365983
Differential Revision: https://reviews.llvm.org/D52851
llvm-svn: 344371
|
|
|
|
|
|
|
| |
I forgot to update some tests that were affected by the escaping of
backticks in the format string, landed in r343471.
llvm-svn: 343502
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After landing r341457, we started seeing a failure on the swift-lldb
bots. The change was correct and pretty straightforward, a DW_OP_constu
was replaced with DW_OP_lit23, the value remaining identical.
0x000000f4: DW_TAG_variable
DW_AT_location (0x00000000
[0x0000000100000a51, 0x0000000100000d47): DW_OP_lit23, DW_OP_stack_value)
DW_AT_name ("number")
However, this broke LLDB.
(Int) number = <extracting data from value failed>
The value was read correctly, but apparently the value's type was different.
When reading a constu it was reading a uint64 (m_type = e_ulonglong) while for
the literal, it got a signed int (m_type = e_sint). This change makes sure we
read the value as an unsigned.
Differential revision: https://reviews.llvm.org/D51730
llvm-svn: 342142
|
|
|
|
|
|
|
|
|
| |
This applies the same workaround as r321271 to other tests. The root
problem is that lldb finds an internal symbol with the same name in the
debug info of system libraries, and then fails to disambiguate between
the two.
llvm-svn: 341235
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bitfield accesses.
Summary:
For some bitfield patterns (like the one added by this commit), Clang will
generate non-regular data types like i24 or i48. This patch follows a
pretty naive approach of just bumping the type size to the next power of 2.
DataExtractor know how to deal with weird sizes. The operations on Scalar
do not know how to deal with those types though, so we have to legalize the
size when creating a Scalar.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D51245
llvm-svn: 340880
|
|
|
|
|
|
| |
right and doesn't add much signal.
llvm-svn: 340574
|
|
|
|
| |
llvm-svn: 340573
|
|
|
|
| |
llvm-svn: 340550
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
1) Several tests that are flakey on windows fail the run even if they are marked as expected to be flakey. This is because they fail frequently enough that even a retry won't help
2) Skip several tests on Windows that will occasionally hang rather than failing or exiting. This is causing the entire test suite to hang
Reviewers: asmith, labath, zturner
Reviewed By: zturner
Differential Revision: https://reviews.llvm.org/D50198
llvm-svn: 338769
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The test suite has often unnecessary trailing whitespace, and sometimes
unnecessary trailing lines or a missing final new line. This patch just strips
trailing whitespace/lines and adds missing newlines at the end.
Subscribers: ki.stfu, JDevlieghere, christof, lldb-commits
Differential Revision: https://reviews.llvm.org/D49943
llvm-svn: 338171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: It looks like the test file was copied from TestCPPStaticMethods.py because they have the same name. This means that the two tests will try to write to the same output files and will either overwrite each other's output or occasionally cause failures because they can't both access the same file.
Reviewers: asmith, zturner
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49261
llvm-svn: 336960
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows
Summary:
1) When ReadRegister is called with a null register into on Windows, rather than crashing due to an access violation, simply return false. Not all registers and properties will be read or calculated correctly, but that is consistent with other platforms that also return false in that case
2) Update a couple of tests to reference pr37995 as their reason for failure since it is much more accurate. Support for floating point registers doesn't exist on Windows at all, rather than having issues.
Reviewers: asmith, labath, zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48844
llvm-svn: 336147
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running the test suite with .debug_names a bunch of tests were
failing because GetCompleteObjCClass was not yet implemented for
DebugNamesDWARFIndex. This patch adds the required logic.
We use the .debug_names to find the Objective-C class and then rely on
DW_AT_APPLE_objc_complete_type to find the complete type. If we can't
find it or the attribute is not supported, we return a list of potential
complete types.
Differential revision: https://reviews.llvm.org/D48596
llvm-svn: 335776
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libstdc++ will soon be dropped from the android NDK. This patch makes
sure we are prepared for that by using libc++ in tests by default (i.e.,
except for libstdc++ data formatter tests).
Only a couple of small tweaks were needed to make this work:
- Add the libc++ include paths to CXXFLAGS only. This was necessary to
make the tests compile with -fmodules. The modules tests have been
disabled, but this way, they will be ready for them if they are
enabled.
- in one test I had to add an explicit std::string copy to make sure the
copy constructor is there for the expression evaluator to find it.
llvm-svn: 335344
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a modules build, android is very picky about which symbols are
visible after including libc++ headers (e.g. <cstdio> defines only
std::printf and not ::printf).
This consolidates the tests where this was an issue to always include
the <c???> version of the headers and prefixes the symbols with std:: as
necessary.
Apart from that, there is no functional change in the tests.
llvm-svn: 335149
|
|
|
|
| |
llvm-svn: 334614
|
|
|
|
|
|
|
|
|
|
|
|
| |
This method is used to find complete definitions of a type when one
parses a compile unit with only forward declaration available.
Since it is only accessed from DWARFASTParserClang, it was not
possible/easy to trigger this codepath from lldb-test. Therefore, I
adapt add a debug-names variant to an existing dotest test to cover this
scenario.
llvm-svn: 334516
|
|
|
|
|
|
|
|
| |
Apparently some compilers generate incomplete debug information which
caused the updated test to fail. Therefore I've extracted the new check
into a separate test case with the necessary decorators.
llvm-svn: 334456
|
|
|
|
|
|
|
|
|
|
| |
Before Pavel's change in r334181, we were printing too many global
variables. This patch updates the test suite to ensure we don't regress
again in the future.
rdar://problem/29180927
llvm-svn: 334454
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: They all correspond to bugs that are already logged and I've added the appropriate (or most appropriate) bug numbers. This leaves only a handful of failing tests.
Reviewers: asmith, zturner, labath
Reviewed By: zturner
Subscribers: eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D47892
llvm-svn: 334210
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In r331719, I changed Module::FindTypes not to limit the amount
of types returned by the Symbol provider, because we want all
possible matches to be able to filter them. In one code path,
the filtering was applied to the TypeList without changing the
number of types that gets returned. This is turn could cause
consumers to access beyond the end of the TypeList.
This patch fixes this case and also adds an assertion to
TypeList::GetTypeAtIndex to catch those obvious programming
mistakes.
Triggering the condition in which we performed the incorrect
access was not easy. It happened a lot in mixed Swift/ObjectiveC
code, but I was able to trigger it in pure Objective C++ although
in a contrieved way.
rdar://problem/40254997
llvm-svn: 333786
|
|
|
|
| |
llvm-svn: 333526
|
|
|
|
|
|
|
|
|
| |
Not strictly necessary, but makes the test more robust in case
we end up changing the defaults.
<rdar://problem/40622096>
llvm-svn: 333466
|