Summary:
This adds support for building libc++ tests when targetting android. The
tests are still not passing due to several other problems, but this way
we can at least build them.
Reviewers: eugene, EricWF, danalbert
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D30737
llvm-svn: 297616
The toolchain directory for arm android targets was computed
incorrectly. The architecture part should be arm, and the environment
part androideabi. This fixes that.
llvm-svn: 297279
Prior to MSVC 2015 we had to manually include this header any
time we were going to include <thread> or <future> due to a
bug in MSVC's STL implementation. This has been fixed in MSVC
for some time now, and we require VS 2015 minimum, so we can
remove this across all subprojects.
llvm-svn: 296906
$(realpath), which I guess is a make builtin, gives strange results on
Windows. $(shell realpath) invokes the gnuwin external binary, which
works correctly.
llvm-svn: 296876
Summary:
This teaches the test makefiles about the Android NDK, so we are able to
run the tests without first going through the make_standalone_toolchain
script. The motivation for this is the ability to run both libc++ and
libstdc++ tests together, which previously was not possible because
make_standalone_toolchain bakes in the STL to use during toolchain
creation time. The support for this is not present yet -- this change
only make sure we don't regress for existing funcionality (gcc w/
libstdc++). Clang and libc++ support will be added later.
I've checked that the mips android targets compile after this change,
but I have no way of checking whether this breaks anything. If you are
reading this and it broke you, let me know.
Reviewers: tberghammer, danalbert
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D30410
llvm-svn: 296869
This time it should actually work. The previous implementaiton was not
getting the linker or compiler flag set correctly in all the right
situations. By moving the check down and basing it of whether or not CXX
is set I we can have the logic to add the flags exist only once for the
linker and once for the compiler instead of duplicating it.
llvm-svn: 284756
This patch is causing a lot of issues on bots that I didn't see in local testing. I'm going to have to work on this. Reverting for now while I sort it out.
llvm-svn: 284565
Summary:
When building the LLDB test programs, if your CC is clang it actually isn't safe to make CXX a string replace of "clang -> clang++". This falls down on unix configurations if your compiler is clang-${version}.
A safer approach is to use the "--driver-mode=g++" option to tell clang to act like clang++.
Reviewers: tfiala, zturner, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D25753
llvm-svn: 284550
VS 2015 and higher begin making use of c++14 in their standard
library headers. As such, -std=c++11 makes it so you can't compile
trivial programs. Bump this to -std=c++14 when this situation is
detected.
llvm-svn: 281420
This wasn't actually a problem with the reformat, but rather a
problem with Visual Studio 2015 Update 3, which uses some c++14
features in its standard libraries. So we had to change -std=c++11
to -std=c++14.
llvm-svn: 280759
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
This commit is causing problems on gcc-* compiler with version number sufix.
Requires a new solution will post a follow up patch.
Differential revision: https://reviews.llvm.org/D20386
llvm-svn: 277453
Android API <= 16 header do not have these symbols defined, but the kernel does support the
relevant calls. And in general, since these calls are on a best-effort basis, it won't hurt even
if we try to run in on a really ancient kernel.
llvm-svn: 275393
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
The adding of <atomic> to test_common.h broke 12 tests on Darwin. We work around this by not including <atomic> when building on darwin for libstdc++ tests.
llvm-svn: 269372
Summary:
TestExitDuringStep was very rarely hanging on the buildbots. I can't be sure, but I believe this
was because of the fact that it declared its pseudo_barrier variable as "volatile int", which is
not sufficient to guarantee corectness (also, all other tests used atomic variables for this, and
they were passing reliably AFAIK). Besides switching to an atomic variable in this test as well,
I have also took this opportunity to unify all the copies of the pseudo_barrier code to a single
place to reduce the chance of this happening again.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20065
llvm-svn: 269025
This patch adds support for Linux on SystemZ:
- A new ArchSpec value of eCore_s390x_generic
- A new directory Plugins/ABI/SysV-s390x providing an ABI implementation
- Register context support
- Native Linux support including watchpoint support
- ELF core file support
- Misc. support throughout the code base (e.g. breakpoint opcodes)
- Test case updates to support the platform
This should provide complete support for debugging the SystemZ platform.
Not yet supported are optional features like transaction support (zEC12)
or SIMD vector support (z13).
There is no instruction emulation, since our ABI requires that all code
provide correct DWARF CFI at all PC locations in .eh_frame to support
unwinding (i.e. -fasynchronous-unwind-tables is on by default).
The implementation follows existing platforms in a mostly straightforward
manner. A couple of things that are different:
- We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers,
since some registers (access register) reside at offsets in the user area
that are multiples of 4, but the PTRACE_PEEKUSER interface only allows
accessing aligned 8-byte blocks in the user area. Instead, we use a s390
specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that
allows accessing a whole block of the user area in one go, so in effect
allowing to treat parts of the user area as register sets.
- SystemZ hardware does not provide any means to implement read watchpoints,
only write watchpoints. In fact, we can only support a *single* write
watchpoint (but this can span a range of arbitrary size). In LLDB this
means we support only a single watchpoint. I've set all test cases that
require read watchpoints (or multiple watchpoints) to expected failure
on the platform. [ Note that there were two test cases that install
a read/write watchpoint even though they nowhere rely on the "read"
property. I've changed those to simply use plain write watchpoints. ]
Differential Revision: http://reviews.llvm.org/D18978
llvm-svn: 266308
Summary:
On linux we need the process to give us special permissions before we can attach to it.
Previously, the code for this was copied into every file that needed it. This moves the code to a
central place to reduce code duplication.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15992
llvm-svn: 257319
Summary: Also xfailed for GCC as there is an problem with debug info generation.
Reviewers: granata.enrico
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15657
llvm-svn: 256067
Summary:
DWARF 5 proposes a reinvented .debug_macro section. This change follows
that spec.
Currently, only GCC produces the .debug_macro section and hence
the added test is annottated with expectedFailureClang.
Reviewers: spyffe, clayborg, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15437
llvm-svn: 255729
Both of these markers are used in the test suit for annotating when a
test needs multi threaded support. Previously they had slightly
different meening but they converged to the point where they are used
interchangably. This CL removes the ENABLE_STD_THREADS one to simplify
the test suite and avoid some confusion.
Differential revision: http://reviews.llvm.org/D15498
llvm-svn: 255641
SUMMARY:
For MIPS, ARCH is specified without m.
Reviewers: clayborg
Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
Differential Revision: http://reviews.llvm.org/D14978
llvm-svn: 254376
-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 allows for command-line debugging of iOS simulator binaries (as long as UI is not required, or a full UI simulator has previously been otherwise launched), as well as execution of the LLDB test suite on the iOS simulator
This is known to compile on OSX 10.11 GM - feedback from people on other platforms and/or older versions of OSX as to the buildability of this code is greatly appreciated
llvm-svn: 252112
This is the conclusion of an effort to get LLDB's Python code
structured into a bona-fide Python package. This has a number
of benefits, but most notably the ability to more easily share
Python code between different but related pieces of LLDB's Python
infrastructure (for example, `scripts` can now share code with
`test`).
llvm-svn: 251532
