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
With this patch, the client will package up all the required
inputs into a compressed zip file, establish a connection to the
server, send the input to the server, and wait for the server to
send a response (in this case the response is just echoed back to
the client).
This gets the network communication in place, and in a subsequent
patch I will follow up with the code that actually runs swig on
the server and sends back the output instead of echoing back the
input.
llvm-svn: 254023
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
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
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
-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
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 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
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
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
Tamas Berghammer