| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This enables a couple of tests which have been shown to run reliably on the
linux x86 buildbot. If you see a failure after this commit, feel free to add
the xfail back, but please make it as specific as possible (i.e., try to make
it not cover i386/x86_64 with clang-3.5, clang-3.9 or gcc-4.9).
llvm-svn: 272326
|
|
|
|
|
|
| |
This reverts commit r272024 as it is not windows-compatible.
llvm-svn: 272062
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a lldbinline test's source file changed language, then the Makefile wasn't
updated. This was a problem if the Makefile was checked into the repository.
Now lldbinline.py always regenerates the Makefile and asserts if the
newly-generated version is not the same as the one already there. This ensures
that the repository will never be out of date without a buildbot failing.
http://reviews.llvm.org/D21032
llvm-svn: 272024
|
|
|
|
| |
llvm-svn: 271618
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some compilers do not mark up C++ functions as extern "C" in the DWARF, so LLDB
has to fall back (if it is about to give up finding a symbol) to using the base
name of the function.
This fix also ensures that we search by full name rather than "auto," which
could cause unrelated C++ names to be found. Finally, it adds a test case.
<rdar://problem/25094302>
llvm-svn: 271551
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds the capability of building test inferiors
with the -gmodules flag to enable module debug info support.
Windows is excluded per @zturner.
Reviewers: granata.enrico, aprantl, zturner, labath
Subscribers: zturner, labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D19998
llvm-svn: 270848
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
using stdio in tests does not work on windows, and it is not completely reliable on linux.
Avoid using stdio in this test, as it is not necessary for this purpose.
Reviewers: clayborg
Subscribers: lldb-commits, zturner
Differential Revision: http://reviews.llvm.org/D20567
llvm-svn: 270831
|
|
|
|
|
|
|
|
| |
TestBSDArchives.py and TestWatchLocation.py fail due to unicode error and bug has already been reported for arm and macOSx.
TestConstVariables.py fails because lldb cant figure out frame variable type when used in expr.
llvm-svn: 270780
|
|
|
|
|
|
|
|
| |
This fails on FreeBSD 10 with the system compiler, Clang 3.4.1.
llvm.org/pr27845
llvm-svn: 270603
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20540
llvm-svn: 270493
|
|
|
|
| |
llvm-svn: 270490
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
m_decl_objects is problematic because it assumes that each VarDecl has a unique
variable associated with it. This is not the case in inline contexts.
Also the information in this map can be reconstructed very easily without
maintaining the map. The rest of the testsuite passes with this cange, and I've
added a testcase covering the inline contexts affected by this.
<rdar://problem/26278502>
llvm-svn: 270474
|
|
|
|
|
|
|
| |
Macros work again after Clang r269554. This testcase just needed some small
tweaks to get it going again.
llvm-svn: 269704
|
|
|
|
|
|
|
|
|
| |
Remove XFAIL from some tests that now pass.
Add XFAIL to some tests that now fail.
Fix a crasher where a null pointer check isn't guarded.
Properly handle all types of errors in SymbolFilePDB.
llvm-svn: 269454
|
|
|
|
|
|
|
|
| |
NamespaceLookupTestCase.test_scope_lookup_before_using_with_run_command on linux
test appears to be passing now.
llvm-svn: 268923
|
|
|
|
|
|
|
| |
the test should no longer crash, but we need to investigate why ToT clang still generates debug
info we don't understand.
llvm-svn: 268619
|
|
|
|
| |
llvm-svn: 268616
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19943
llvm-svn: 268574
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Fixed semicolon placement in the lambda in the test itself.
2. Fixed lldbinline tests in general so that we don't attempt tests on platforms that don't use the given type of debug info. (For example, no DWO tests on Windows.) This fixes one of the two failures on Windows. (TestLambdas.py was the only inline test that wasn't XFailed or skipped on Windows.)
3. Set the error string in IRInterpreter::CanInterpret so that the caller doesn't print (null) instead of an explanation. I don't entirely understand the error, so feel free to suggest a better wording.
4. XFailed the test on Windows. The interpreter won't evaluate the lambda because the module has multiple function bodies. I don't exactly understand why that's a problem for the interpreter nor why the problem arises only on Windows.
Differential Revision: http://reviews.llvm.org/D19606
llvm-svn: 268573
|
|
|
|
|
|
|
|
|
| |
Also added a data formatter that presents them as structs if you use frame
variable to look at their contents. Now the blocks testcase works.
<rdar://problem/15984431>
llvm-svn: 268307
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D19751
llvm-svn: 268135
|
|
|
|
|
|
|
|
|
| |
a bitfield member doesn't lie within the bit bounds of the type itself, just leave it out so we don't get clang asserting and killing our IDE when it gets unhappy with the information.
https://llvm.org/bugs/show_bug.cgi?id=27515
<rdar://problem/21082998>
llvm-svn: 268110
|
|
|
|
|
|
|
|
| |
or asserting.
<rdar://problem/23776428>
llvm-svn: 268098
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In templated const functions, trying to run an expression would produce the
error
error: out-of-line definition of '$__lldb_expr' does not match any declaration
in 'foo' member declaration does not match because it is const qualified
error: 1 error parsing expression
which is no good. It turned out we don't actually need to worry about "const,"
we just need to be consistent about the declaration of the expression and the
FunctionDecl we inject into the class for "this."
Also added a test case.
<rdar://problem/24985958>
llvm-svn: 268083
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Started failing after rL267895.
Possibly related to http://llvm.org/pr27510.
Reviewers: labath, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D19680
llvm-svn: 267923
|
|
|
|
|
|
|
|
|
|
| |
$__lldb_expr."
This reverts commit r267833 as it breaks the build. It looks like some work in progress got
committed together with the actual fix, but I'm not sure which one is which, so I'll revert the
whole patch and let author resumbit it after fixing the build error.
llvm-svn: 267861
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In templated const functions, trying to run an expression would produce the
error
error: out-of-line definition of '$__lldb_expr' does not match any declaration in 'foo'
member declaration does not match because it is const qualified
error: 1 error parsing expression
which is no good. It turned out we don't actually need to worry about "const,"
we just need to be consistent about the declaration of the expression and the
FunctionDecl we inject into the class for "this."
Also added a test case.
<rdar://problem/24985958>
llvm-svn: 267833
|
|
|
|
|
|
| |
The flakyness is no longer reproducible, and the tests seem to be passing reliably now.
llvm-svn: 267704
|
|
|
|
|
|
|
|
| |
Use __attribute__((regparm(x))) to ensure the compiler enregisters at least some arguments when calling functions.
Differential Revision: http://reviews.llvm.org/D19548
llvm-svn: 267616
|
|
|
|
|
|
|
| |
tracked by:
https://llvm.org/bugs/show_bug.cgi?id=27515
llvm-svn: 267421
|
|
|
|
|
|
|
| |
Test added in r267248 exposed a bug in handling of dwarf produced by clang>=3.9, which causes a
crash during expression evaluation. Skip the test until this is sorted out.
llvm-svn: 267407
|
|
|
|
|
|
|
|
| |
Some older versions of clang emitted bit offsets that were negative and these bitfields would have their bitfield-ness stripped off and it would cause a clang assertion in clang assertions were enabled. I updated the bitfield C test to make sure we don't regress.
<rdar://problem/21082998>
llvm-svn: 267248
|
|
|
|
|
|
| |
information when using precompiled headers and -gmodules.
llvm-svn: 266791
|
|
|
|
| |
llvm-svn: 266400
|
|
|
|
|
|
| |
<rdar://problem/25739133>
llvm-svn: 266397
|
|
|
|
|
|
| |
<rdar://problem/25738696>
llvm-svn: 266389
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A number of test cases were failing on big-endian systems simply due to
byte order assumptions in the tests themselves, and no underlying bug
in LLDB.
These two test cases:
tools/lldb-server/lldbgdbserverutils.py
python_api/process/TestProcessAPI.py
actually check for big-endian target byte order, but contain Python errors
in the corresponding code paths.
These test cases:
functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py
functionalities/data-formatter/synthcapping/TestSyntheticCapping.py
lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
python_api/sbdata/TestSBData.py (first change)
could be fixed to check for big-endian target byte order and update the
expected result strings accordingly. For the two synthetic tests, I've
also updated the source to make sure the fake_a value is always nonzero
on both big- and little-endian platforms.
These test case:
python_api/sbdata/TestSBData.py (second change)
functionalities/memory/cache/TestMemoryCache.py
simply accessed memory with the wrong size, which wasn't noticed on LE
but fails on BE.
Differential Revision: http://reviews.llvm.org/D18985
llvm-svn: 266315
|
|
|
|
| |
llvm-svn: 266054
|
|
|
|
| |
llvm-svn: 265527
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test sets the compiler optimization level to -O1 and
makes some assumptions about how local frame vars will be
stored (i.e. in registers). These assumptions are not always
true.
I did a first-pass set of improvements that:
(1) no longer assumes that every one of the target locations has
every variable in a register. Sometimes the compiler
is even smarter and skips the register entirely.
(2) simply expects one of the 5 or so variables it checks
to be in a register.
This test probably passes on a whole lot more systems than it
used to now. This is certainly true on OS X.
llvm-svn: 265498
|
|
|
|
|
|
|
| |
The test was failing on windows because the clean rule (which is executed even if the test is
skipped) returned an error there.
llvm-svn: 265140
|
|
|
|
|
|
| |
<rdar://problem/25447765>
llvm-svn: 264914
|
|
|
|
|
|
|
| |
the main reason is that our decorator contains extra fluff to "expect" crashes (which seem to
happen occasionaly on the android buildbot).
llvm-svn: 263633
|
|
|
|
|
|
|
|
|
|
| |
In r262970 this was changed from xfail Clang < 3.5 to > 3.5, but it
still fails on FreeBSD 10's system Clang 3.4.1 so assume it fails on
all versions.
llvm.org/pr26937
llvm-svn: 263467
|
|
|
|
|
|
|
|
|
|
| |
struct/union
When the parent of an expression is anonymous, skip adding '.' or '->' before the expression name.
Differential Revision: http://reviews.llvm.org/D18005
llvm-svn: 263166
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
GCC does not emit DW_AT_data_member_location for members of a union.
Starting with a 0 value for member locations helps is reading union types
in such cases.
Reviewers: clayborg
Subscribers: ldrumm, lldb-commits
Differential Revision: http://reviews.llvm.org/D18008
llvm-svn: 263085
|
|
|
|
|
|
|
|
| |
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17972
llvm-svn: 262970
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The System-V x86_64 ABI requires floating point values to be passed
in 128-but SSE vector registers (xmm0, ...). When printing such a
variable this currently yields an <invalid load address>.
This patch makes LLDB's DWARF expression evaluator accept 128-bit
registers as scalars. It also relaxes the check that the size of the
result of the DWARF expression be equal to the size of the variable to a
greater-than. DWARF defers to the ABI how smaller values are being placed
in a larger register.
Implementation note: I found the code in Value::SetContext() that changes
the m_value_type after the fact to be questionable. I added a sanity check
that the Value's memory buffer has indeed been written to (this is
necessary, because we may have a scalar value in a vector register), but
really I feel like this is the wrong place to be setting it.
Reviewed by Greg Clayton.
http://reviews.llvm.org/D17897
rdar://problem/24944340
llvm-svn: 262947
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The inlining semantics for C and C++ are different, which affects the test's expectation of the number of times the function should appear in the binary. In the case of this test, C semantics means there should be three instances of inner_inline, while C++ semantics means there should be only two.
On Windows, clang uses C++ inline semantics even for C code, and there doesn't seem to be a combination of compiler flags to avoid this.
So, for consistency, I've recast the test to use C++ everywhere. Since the test resided under lang/c, it seemed appropriate to move it to lang/cpp.
This does not address the other XFAIL for this test on Linux/gcc. See https://llvm.org/bugs/show_bug.cgi?id=26710
Differential Revision: http://reviews.llvm.org/D17650
llvm-svn: 262255
|
|
|
|
|
|
|
|
|
| |
"sif <target function>" - i.e. step-into-function
to allow you to step through a complex calling sequence into a particular function that may span multiple lines. Also some
test cases for this and the --step-target feature.
llvm-svn: 261953
|