| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
llvm-svn: 301918
|
| |
|
|
|
|
| |
This fixes a couple of tests when using android clang as a compiler.
llvm-svn: 300045
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This aims to replace the different decorators we've had on each libc++
test with a single solution. Each libc++ will be assigned to the
"libc++" category and a single central piece of code will decide whether
we are actually able to run libc++ test in the given configuration by
enabling or disabling the category (while giving the user the
opportunity to override this).
I started this effort because I wanted to get libc++ tests running on
android, and none of the existing decorators worked for this use case:
- skipIfGcc - incorrect, we can build libc++ executables on android
with gcc (in fact, after this, we can now do it on linux as well)
- lldbutil.skip_if_library_missing - this checks whether libc++.so is
loaded in the proces, which fails in case of a statically linked
libc++ (this makes copying executables to the remote target easier to
manage).
To make this work I needed to split out the pseudo_barrier code from the
force-included file, as libc++'s atomic does not play well with gcc on
linux, and this made every test fail, even though we need the code only
in the threading tests.
So far, I am only annotating one of the tests with this category. If
this does not break anything, I'll proceed to update the rest.
Reviewers: jingham, zturner, EricWF
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D30984
llvm-svn: 299028
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
building executables with the NDK clang requires -target and
-gcc-toolchain arguments.
Reviewers: eugene, danalbert
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D30574
llvm-svn: 297145
|
| |
|
|
|
|
|
| |
realpath is not available as an executable on mac. I give up, I am just
going to leave the path with ..'s in it.
llvm-svn: 296885
|
| |
|
|
|
|
|
|
| |
$(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
|
