Centralize libc++ test skipping logic
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
2017-03-30 05:01:14 +08:00
|
|
|
#include <atomic>
|
2019-09-05 03:36:29 +08:00
|
|
|
|
|
|
|
|
// Note that although hogging the CPU while waiting for a variable to change
|
|
|
|
|
// would be terrible in production code, it's great for testing since it avoids
|
|
|
|
|
// a lot of messy context switching to get multiple threads synchronized.
|
Centralize libc++ test skipping logic
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
2017-03-30 05:01:14 +08:00
|
|
|
|
|
|
|
|
typedef std::atomic<int> pseudo_barrier_t;
|
|
|
|
|
|
2019-09-05 03:36:29 +08:00
|
|
|
#define pseudo_barrier_wait(barrier) \
|
|
|
|
|
do \
|
|
|
|
|
{ \
|
|
|
|
|
--(barrier); \
|
|
|
|
|
while ((barrier).load() > 0) \
|
|
|
|
|
; \
|
|
|
|
|
} while (0)
|
2019-09-04 01:04:04 +08:00
|
|
|
|
2019-09-05 03:36:29 +08:00
|
|
|
#define pseudo_barrier_init(barrier, count) \
|
|
|
|
|
do \
|
|
|
|
|
{ \
|
|
|
|
|
(barrier) = (count); \
|
|
|
|
|
} while (0)
|