| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
The test is flakey but it fails too often with gcc 4.9.2 on x86_64 to
be marked only as expected flakey.
llvm-svn: 254194
|
|
|
|
|
|
|
| |
Previously it tried to write a bit in the FPSCR register marked as
do not modify what failed on some device.
llvm-svn: 254166
|
|
|
|
|
|
|
|
| |
These tests were fixed by r253026 but they was failing on the linux
build bot because of a system setup problem. Remove xfail from them
after we fixed the build bot.
llvm-svn: 254163
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D15010
llvm-svn: 254153
|
|
|
|
|
|
| |
test reliably passed last 100 buildbot runs. Enable it and see what happens.
llvm-svn: 254072
|
|
|
|
|
|
|
|
|
|
| |
FreeBSD
On FreeBSD we may get Clang via CC=cc or CC=/usr/bin/cc.
llvm.org/pr25626
llvm-svn: 254006
|
|
|
|
|
|
|
|
|
|
| |
This test was already expectedFlakeyLinux for occasional failures on the
Linux buildbot. It seems the new FreeBSD buildbot fails the same way on
occasion.
llvm.org/pr25172
llvm-svn: 254002
|
|
|
|
|
|
|
|
|
| |
These pass on my FreeBSD stable/10 desktop and my (not-yet-connected)
FreeBSD 11-CURRENT buildbot
llvm.org/pr20548
llvm-svn: 254001
|
|
|
|
|
|
|
|
|
| |
This passes on my FreeBSD stable/10 desktop and my new FreeBSD
11-current buildbot (which is not yet hooked up to the buildmaster).
llvm.org/pr18190
llvm-svn: 254000
|
|
|
|
|
|
| |
llvm.org/pr25624
llvm-svn: 253998
|
|
|
|
|
|
|
|
| |
targets.
Differential revision: http://reviews.llvm.org/D14823
llvm-svn: 253973
|
|
|
|
|
|
|
|
| |
Also adds SB API to save a core and tests that use it.
Differential Revision: http://reviews.llvm.org/D14793
llvm-svn: 253734
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This reverts commit 70dca28976ee8137acce2cc203dd394f4d761276.
Reviewers: amccarth, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14881
llvm-svn: 253704
|
|
|
|
|
|
| |
the test yet
llvm-svn: 253697
|
|
|
|
|
|
|
|
| |
Accidentally commited before I was done.
This reverts commit 2ec2da4ee52780582d5e9c88b2e982a688fbdbe1.
llvm-svn: 253685
|
|
|
|
| |
llvm-svn: 253684
|
|
|
|
| |
llvm-svn: 253683
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This reverts commit 251965377bdfb6227eea42c12a792c059e4e8a4b
as a test marked "skipIf(compiler='gcc')" runs when testing with GCC.
Reviewers: amccarth
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14852
llvm-svn: 253631
|
|
|
|
| |
llvm-svn: 253623
|
|
|
|
|
|
| |
that the 'frame variable' command can still find the members of such union as if they were top-level variables in the current scope
llvm-svn: 253613
|
|
|
|
|
|
| |
infrastructure; the tests are now xfailed on Darwin pending investigation
llvm-svn: 253604
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fms-compatibility-version defaults to VS 2013. When using
VS 2015, this will lead to compilation failures of the test
inferiors in the C++ standard library for language conformance
reasons.
The fix here is to simply pass -fms-compatibility-version=19.0 when
we detect that a VS 2015 compiler is present. Even though we're
actually using clang to do the compilation, clang uses this same
detection algorithm to determine the location of the standard
library. So this check is tantanmount to saying "If clang is going
to find MSVC 2015's standard library, then pass 19.0 for
-fms-compatibility-version.
llvm-svn: 253589
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain
Summary: This patch check whether first register is readable.
Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan
Reviewers: clayborg, ovyalov, jaydeep
Differential: http://reviews.llvm.org/D14635
llvm-svn: 253555
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14784
llvm-svn: 253505
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14765
llvm-svn: 253488
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes two issues:
1) Popen needs to be used with universal_newlines=True by default.
This elicits automatic decoding from bytes -> string in Py3,
and has no negative effects in other Py versions.
2) The swig typemaps for converting between string and (char*, int)
did not work correctly when the length of the string was 0,
indicating an error. In this case we would try to construct a
string from uninitialized data.
3) Ironically, the bug mentioned in #2 led to a test passing on
Windows that was actually broken, because the test was written
such that the assertion was never even getting checked, so it
passed by default. So we additionally fix this test to also
fail if the method errors. By fixing this test it's now broken
on Windows, so we also xfail it.
llvm-svn: 253487
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain
Summary: The break is opcode for breakpoint instruction.
Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan
Reviewers: clayborg, ovyalov, jaydeep
Differential: http://reviews.llvm.org/D14634
llvm-svn: 253445
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain
Summary: The self.getArchitecture() returns the architecture based on the value of -A flag passed to dotest.py script.
There are many possible values for MIPS to this option (like mips32r2, mips32r6, mips64, mips64r2,.... ).
This patch uses re.match(mips,arch) to check if architecture string starts with mips.
Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan, jaydeep
Reviewers: clayborg, ovyalov
Differential: http://reviews.llvm.org/D14493
llvm-svn: 253444
|
|
|
|
|
|
|
|
| |
breakpoint as "file address" so that the address breakpoint will track that
module even if it gets loaded in a different place. Also fixed the Address
breakpoint resolver so that it handles this tracking correctly.
llvm-svn: 253308
|
|
|
|
|
|
|
|
|
|
|
| |
Current versions of SWIG have a bug with Python 3 that causes
Python to assert when iterating over a generator. This patch
skips the test for the right combination of Python version and
SWIG version. I'm attempting to upstream a patch to SWIG to
fix this in a subsequent as-of-yet unreleased version, but
I don't know how long that will take.
llvm-svn: 253273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to expectedFailureAll ..." with fix
Summary:
- Re-Commit r253106
- Initialize self.debug_info in Base::setUp()
- Fix argument order when calling check_list_or_lambda for compiler
Reviewers: jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14673
llvm-svn: 253272
|
|
|
|
| |
llvm-svn: 253263
|
|
|
|
|
|
|
|
| |
to expectedFailureAll to reverse"
This reverts commit r253106.
llvm-svn: 253197
|
|
|
|
|
|
| |
This removes a lot of code, which is A Good Thing(TM)
llvm-svn: 253140
|
|
|
|
|
|
|
|
| |
expectedFailureAll to reverse
the sense of the test.
llvm-svn: 253106
|
|
|
|
| |
llvm-svn: 253101
|
|
|
|
|
|
|
|
| |
to break on. Rerunning
was being foiled by ASLR.
llvm-svn: 253094
|
|
|
|
| |
llvm-svn: 253042
|
|
|
|
|
|
|
| |
these decorators were two of many removed in r253026. Unlike others, these tests still seem to be
failing...
llvm-svn: 253034
|
|
|
|
| |
llvm-svn: 253028
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change Test-rdar-12481949.py to expect GetValueAsUnsigned() to return
0xffffffff if the variable is an int32_t (signed, 4 byte integer) with
value of -1. The previous expectation where we expected the value to be
0xffffffffffffffff doesn't make sense as nothing explains why we would
treat it as an 8 byte value.
This CL also removes a hack from Scalar::ULongLong what was most likely
added to get this test passing as it only worked in case the value of
the variable is -1 and didn't make any sense even in that case.
Differential revision: http://reviews.llvm.org/D14611
llvm-svn: 253027
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Reason of both bugs:
1. For the very first frame, Unwinder doesn't check the validity
of Full UnwindPlan before creating StackFrame from it:
When 'process launch' command is run after setting a breakpoint
in inferior, the Unwinder runs and saves only Frame 0 (the frame
in which breakpoint was set) in thread's StackFrameList i.e.
m_curr_frames_sp. However, it doesn't check the validity of the
Full UnwindPlan for this frame by unwinding 2 more frames further.
2. Unwinder doesn't update the CFA value of Cursor when Full UnwindPlan
fails and FallBack UnwindPlan succeeds in providing valid CFA values
for frames:
Sometimes during unwinding of stack frames, the Full UnwindPlan
inside the RegisterContextLLDB object may fail to provide valid
CFA values for these frames. Then the Fallback UnwindPlan is used
to unwind the frames.
If the Fallback UnwindPlan succeeds, then it provides a valid new
CFA value. The RegisterContextLLDB::m_cfa field of Cursor object
is updated during the Fallback UnwindPlan execution. However,
UnwindLLDB misses the implementation to update the 'cfa' field
of this Cursor with this valid new CFA value.
- This patch fixes both these issues.
- Remove XFAIL in test files corresponding to these 2 Bugs
Change-Id: I932ea407545ceee2d628f946ecc61a4806d4cc86
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: jingham, lldb-commits, jasonmolenda
Subscribers: lldb-commits, ovyalov, tberghammer
Differential Revision: http://reviews.llvm.org/D14226
llvm-svn: 253026
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14591
llvm-svn: 252950
|
|
|
|
| |
llvm-svn: 252831
|
|
|
|
|
|
|
|
|
| |
on Darwin.
Tracked by:
https://llvm.org/bugs/show_bug.cgi?id=25486
llvm-svn: 252707
|
|
|
|
|
|
|
| |
We have several tests that TIMEOUT under heavy load but just need a bit
more time to complete.
llvm-svn: 252703
|
|
|
|
|
|
|
|
|
|
| |
This test fails most of the time when run under heavy load. The dsym
variant doesn't seem to be failing.
Tracking XFAIL marker with:
https://llvm.org/bugs/show_bug.cgi?id=25485
llvm-svn: 252702
|
|
|
|
|
|
|
| |
See the following tracking bug:
https://llvm.org/bugs/show_bug.cgi?id=25484
llvm-svn: 252699
|
|
|
|
| |
llvm-svn: 252657
|
|
|
|
| |
llvm-svn: 252642
|