| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 349700
|
| |
|
|
| |
llvm-svn: 349692
|
| |
|
|
|
|
| |
This test passes with the native reader, so run it in both modes.
llvm-svn: 349675
|
| |
|
|
|
|
|
|
|
|
|
| |
We had a use after free where we were assigning the result of a function
that returned a string to a StringRef. After fixing this use after
free, one of the DIA PDB tests now passes with the native PDB reader,
so we enable the test under native mode as well. The goal is to
eventually make all the tests pass under both, at which point we can
disable them all under DIA mode.
llvm-svn: 349673
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
region" command
Prior to this change we would show the name of the section that a memory region belonged to but not its actual region name. Now we show this,. Added a test that reuses the regions-linux-map.dmp minidump file to test this and verify the correct region names for various memory regions.
Differential Revision: https://reviews.llvm.org/D55854
llvm-svn: 349658
|
| |
|
|
|
|
|
|
|
|
|
| |
The build.py script always runs the compiler in C++ mode, regardless of
the file extension. This results in mangled names presented to the
linker which in turn cannot find the printf symbol.
While we figure out how to solve this issue I've turned the source file
into a cpp file and added extern c. This should unbreak the bots.
llvm-svn: 349642
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently spawnLldbMi accepts both lldb-mi options and executable to debug as
a single parameter. Split them.
As in D55859 we will need to execute one lldb-mi command before loading the
exe. Therefore we can no longer use the exe as lldb-mi command-line parameter
as then there is no way to execute a command before loading exe specified as
lldb-mi command-line parameter.
LocateExecutableSymbolFileDsym should be static, that is also a little
refactorization.
Differential Revision: https://reviews.llvm.org/D55858
llvm-svn: 349607
|
| |
|
|
| |
llvm-svn: 349580
|
| |
|
|
|
|
| |
TestConvenienceVariables.test
llvm-svn: 349573
|
| |
|
|
|
|
|
|
|
| |
We're linking against libcompression all the time now, we don't need to
fall back to zlib. zlib support will still be used when lldb is built on
linux et al systems, so I'm not removing any of the source support, but
when built on darwin with xcode, we'll be using libcompression.
llvm-svn: 349572
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We reconstruct the AST hierarchy by trying to hack up a mangled
name for the parent type using the child type's mangled name.
This was failing for enums because their tag type is represented
with two letters ("W4") instead of one letter ("T", "U", etc) as
it is with classes, structs, and unions. After accounting for
this we can now correctly determine when an enum is nested
inside of a namespace or a class.
llvm-svn: 349565
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
systems. It has been available in the OS over over three years
now. If lldb doesn't link against -lcompression, it should be an
error.
Allocate a scratch buffer for libcompression to use when decoding
packets, instead of it having to allocate & free one on every call.
Fix a typeo with the size of the buffer that compression_decode_buffer()
is expanding into.
<rdar://problem/41601084>
llvm-svn: 349563
|
| |
|
|
|
|
| |
This allows the tests to pass on Windows as well
llvm-svn: 349562
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on Darwin systems and libcompression has been in the OS for over
three years.
Remove use of / linking to zlib. We'll always have libcompression
available now.
Create a scratch buffer via compression_encode_scratch_buffer_size()
and use it in calls to compression_encode_buffer() to avoid
compression_encode_buffer having to malloc & free a scratch buffer
on each call.
Tested by forcing compression to be enabled on macos native (normally
only enabled on iOS et al devices), running the testsuite.
<rdar://problem/41601084>
llvm-svn: 349553
|
| |
|
|
|
|
| |
Thanks to Pavel Labath for the idea!
llvm-svn: 349550
|
| |
|
|
|
|
| |
Just libcxx should suffice.
llvm-svn: 349546
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed on IRC this morning, when building an in-tree clang for
testing we have to have libcxx and libcxxabi checked out. This is a
common pitfall. Not only are the resulting failures non-obvious, they
only manifest when running the test suite, *after* building lldb and
clang. By making them a hard dependency (on macOS) we fail earlier with
a more useful error message.
Differential revision: https://reviews.llvm.org/D55837
llvm-svn: 349539
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
GnuWin32 installs libxml2 2.4. This isn't recent enough for lldb's
usage and thus the build fails. Searching for libxml2 was disabled
due to this build failure.
However, the gdb-remote plugin requires libxml2 to parse various
gdb-remote protocol packets. Thus check and confirm that the libxml2
version is at least 2.8 and disable it if not.
Reviewers: compnerd, zturner
Reviewed By: compnerd
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D55583
llvm-svn: 349538
|
| |
|
|
| |
llvm-svn: 349533
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The first section header does not define a real section. Instead it is
used for various elf extensions. This patch skips creation of a section
for index 0.
This has one furtunate side-effect, in that it allows us to use the section
header index as the Section ID (where 0 is also invalid). This way, we
can get rid of a lot of spurious +1s in the ObjectFileELF code.
Reviewers: clayborg, krytarowski, joerg, espindola
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D55757
llvm-svn: 349498
|
| |
|
|
|
|
|
| |
instead, create a unique temporary directory, and place the socket file
there.
llvm-svn: 349495
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the "self.assertEqual(thread.GetStopReason(), lldb.eStopReasonSignal)"
was occasionally failing because the stop reason would come out as
"trace" this happened if we issued the interrupt just as the processed
stopped due to single-stepping over the breakpoint (i.e., the it was not
necessary to send any signal).
Fix this by removing the breakpoint before resuming the process. This
ensures the process can run unobstructed.
After this, the test passed 200 consecutive runs successfully for me,
even while the system was under heavy load.
llvm-svn: 349491
|
| |
|
|
|
|
|
| |
The test still fails occasionally (1/100 runs). Upgrade the xfail to
skip.
llvm-svn: 349487
|
| |
|
|
|
|
|
|
|
|
| |
This test was disabled in r326756 as a part of "upstreaming debugserver
support for AVX-512 (zmm register set)". This looks like an error
because both register set and remote stubs are different.
In any case, the test passes now.
llvm-svn: 349485
|
| |
|
|
|
|
|
|
|
|
| |
This test is passing now on linux. The same test is claimed to be flaky
on darwin, so it's possible that's true on linux too. If that's the case
we'll have to skip it here too (or fix it).
I mark the test as not-debug-info-dependent as a drive-by.
llvm-svn: 349482
|
| |
|
|
|
|
|
| |
This test is passing now on linux, and probably has been passing since
r282993.
llvm-svn: 349479
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 349474
|