| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch allows to retrieve an address object for `ValueObject`'s children
retrieved through e.g. `GetChildAtIndex` or `GetChildMemberWithName`. It just
uses the corresponding method of the implementation object `m_impl` to achieve
that.
Reviewers: zturner, JDevlieghere, clayborg, labath, serge-sans-paille
Reviewed By: clayborg
Subscribers: leonid.mashinskiy, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56147
llvm-svn: 351065
|
|
|
|
|
|
| |
This test is flaky on Windows and will occasionally hang or fail.
llvm-svn: 350978
|
|
|
|
|
|
| |
found on http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/32/consoleFull#15046896708254eaf0-7326-4999-85b0-388101f2d404
llvm-svn: 350876
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In python 2, strings and bytes are the same, but they're not in
python 3, hence the return of read() needs an explicit conversion.
While I'm around, rename the return of Popen() from `pipe` to
`process`, as that's what Popen returns.
Reviewers: JDevlieghere, friss, zturner, aprantl, serge-sans-paille
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56517
llvm-svn: 350788
|
|
|
|
| |
llvm-svn: 350559
|
|
|
|
| |
llvm-svn: 350557
|
|
|
|
| |
llvm-svn: 350543
|
|
|
|
| |
llvm-svn: 350537
|
|
|
|
|
|
|
|
| |
recognized arguments
Differential Revision: https://reviews.llvm.org/D56027
llvm-svn: 350376
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is already in use:
lit/lit-lldb-init:
settings set symbols.enable-external-lookup false
packages/Python/lldbsuite/test/lldbtest.py:
self.runCmd('settings set symbols.enable-external-lookup false')
But those are not in effect during MI part of the testsuite. Another problem is
that symbols.enable-external-lookup (read by GetEnableExternalLookup) has been
currently read only by LocateMacOSXFilesUsingDebugSymbols and therefore it had
no effect on Linux.
On Red Hat platforms (Fedoras, RHEL-7) there is DWZ in use and so
MiSyntaxTestCase-test_lldbmi_output_grammar FAILs due to:
AssertionError: error: inconsistent pattern ''^.+?\n'' for state 0x5f
(matched string: warning: (x86_64) /lib64/libstdc++.so.6 unsupported
DW_FORM values: 0x1f20 0x1f21
It is the only testcase with this error. It happens due to:
(lldb) target create "/lib64/libstdc++.so.6"
Current executable set to '/lib64/libstdc++.so.6' (x86_64).
(lldb) b main
warning: (x86_64) /lib64/libstdc++.so.6 unsupported DW_FORM values: 0x1f20 0x1f21
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
which happens only with gcc-base-debuginfo rpm installed (similarly for other packages).
It should also speed up the testsuite as it no longer needs to read
/usr/lib/debug symbols which have no effect (and should not have any effect) on
the testsuite results.
Differential Revision: https://reviews.llvm.org/D55859
llvm-svn: 350368
|
|
|
|
|
|
| |
Thanks to Pavel Labath for the suggestion!
llvm-svn: 350360
|
|
|
|
| |
llvm-svn: 350266
|
|
|
|
|
|
|
|
|
|
| |
TestQueues is failing randomly on green dragon and I suspect it is
because the enqueued threads haven't executed by the time we expect
them. This patch adds file-based synchronization to the queues.
Differential Revision: https://reviews.llvm.org/D56208
llvm-svn: 350247
|
|
|
|
|
|
| |
The quoted bug report (llvm.org/PR20270) was closed in 2014.
llvm-svn: 350160
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Skip a number of tests on Windows that are flakey and will pass/fail unexpectedly every dozen or so runs.
llvm-svn: 349946
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 349861
|
|
|
|
|
|
|
|
| |
recognized arguments by default
Differential Revision: https://reviews.llvm.org/D55954
llvm-svn: 349856
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Several of the tests are now passing. This change is enabling them.
llvm-svn: 349813
|
|
|
|
|
|
| |
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
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This allows the tests to pass on Windows as well
llvm-svn: 349562
|
|
|
|
|
|
| |
Thanks to Pavel Labath for the idea!
llvm-svn: 349550
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Remove the expected-fails for 34538611; using an alternate platform
implementation handles these correctly.
llvm-svn: 349417
|
|
|
|
| |
llvm-svn: 349398
|
|
|
|
|
|
|
|
|
|
| |
make the executable name more unique.
This test is failing sporadically on some bots. By removing the sleep
synchronisation, I'm hoping to get it to fail more reproducibly so I
can investigate what is going on.
llvm-svn: 349397
|
|
|
|
| |
llvm-svn: 349208
|