[GWP-ASan] Mutex implementation [2].

[hctim]

Summary

See D60593 for further information.
This patch pulls out the mutex implementation and the required definitions file.

We implement our own mutex for GWP-ASan currently, because:

1. We must be compatible with the sum of the most restrictive elements of the supporting allocator's build system. Current targets for GWP-ASan include Scudo (on Linux and Fuchsia), and bionic (on Android).
2. Scudo specifies -nostdlib++ -nonodefaultlibs, meaning we can't use std::mutex or mtx_t.
3. We can't use sanitizer_common's mutex, as the supporting allocators cannot afford the extra maintenance (Android, Fuchsia) and code size (Fuchsia) overheads that this would incur.

In future, we would like to implement a shared base mutex for GWP-ASan, Scudo and sanitizer_common. This will likely happen when both GWP-ASan and Scudo standalone are not in the development phase, at which point they will have stable requirements.

[jfb]

Tests?

Seems a shame to duplicate mutex again... Why can't use use the STL's version again? It doesn't allocate.

compiler-rt/lib/gwp_asan/definitions.h

16

You're not using this.

compiler-rt/lib/gwp_asan/mutex.h

33

uint8_t seems easy to inadvertently truncate. If you want to restrict size, make it a template and refuse to compile above a certain size. It's always 10 anyways.

38

You should static_assert that this is always lock free.

43

You should take a reference here, not a pointer.

48

ScopedLock(const ScopedLock&) = delete;

66

Seems like this leading compiler barrier should be above the #if.
You also might as well use something like __atomic_signal_fence instead.

73

You should hard-error on other architectures.

82

This won't compile if __unix__ isn't defined.

[hctim]

• Working copy of mutex.
• >>! In D61923#1502245, @jfb wrote:

[hctim]

In D61923#1502245, @jfb wrote:

Seems a shame to duplicate mutex again... Why can't use use the STL's version again? It doesn't allocate.

We can't use std::mutex as we must be C-compatible (and can't make the strong guarantee that std::mutex is header-only), see https://reviews.llvm.org/D60593#inline-537276.
We also are trying to stay independent of pthread for platform-independentness.
We also can't use a sanitizer_common variant as we don't want to pull in the entirety sanitizer_common as a dependency.

Basically, the roadmap is to create a shared mutex library for sanitizer_common, gwp_asan and scudo to all use.

In D61923#1502245, @jfb wrote:

Tests?

Added some unit tests.

compiler-rt/lib/gwp_asan/mutex.h

33

Seeming as this is an entirely-internal number, I've made it a global instead.

82

Should be guarded by if (COMPILER_RT_HAS_GWP_ASAN) at lib/gwp_asan/CMakeLists.txt:20, but have added explicit error condition here.

[eugenis]

I think the idea is that implementing our own spinlock is not much harder than having 3 platform-specific implementations (posix, window, fuchsia).
Also, scudo_standalone is doing the same ( @cryptoad, why? ).

As Mitch mentioned, we should move the implementation into a common directory. Why not do this now?

[jfb]

In D61923#1502323, @hctim wrote:

In D61923#1502245, @jfb wrote:

Seems a shame to duplicate mutex again... Why can't use use the STL's version again? It doesn't allocate.

We can't use std::mutex as we must be C-compatible

Can you clarify what you mean by this? I don't understand.

(and can't make the strong guarantee that std::mutex is header-only), see https://reviews.llvm.org/D60593#inline-537276.

Have you asked on libcxx-dev? Is there interest in the libc++ community for a stand-alone base?

We also are trying to stay independent of pthread for platform-independentness.

The code I see is clearly not platform independent. Please clarify your reasoning. I can understand if you don't want pthread for a valid reason, but "platform-independence" doesn't make sense here.

We also can't use a sanitizer_common variant as we don't want to pull in the entirety sanitizer_common as a dependency.

What's the restriction that makes it unacceptable?

Basically, the roadmap is to create a shared mutex library for sanitizer_common, gwp_asan and scudo to all use.

I'm asking all these question because they should be in the commit message, and would hopefully have surfaced from the RFC about GWP / Scudo. If those weren't in the RFC that's fine, they should still be in the commit message and you'll want to update the RFC with "while reviewing code we realized *stuff*".

In D61923#1502337, @eugenis wrote:

I think the idea is that implementing our own spinlock is not much harder than having 3 platform-specific implementations (posix, window, fuchsia).
Also, scudo_standalone is doing the same ( @cryptoad, why? ).

Your concerns are backwards. Implementation is a one-time thing, maintenance is an ongoing concern and it way overshadows implementation concerns. In particular, a variety of multicore code that does its own locking is much harder to tune at the system-wide level compared to a single thing that's tuned for each application. I'm not saying a separate mutex doesn't make sense, what I'm saying is that experience shows your above reasoning to be generally invalid. I'm totally willing to believe that there's a very good reason to have your own mutex here, but you gotta explain it.

compiler-rt/lib/gwp_asan/definitions.h

15

The undef above doesn't seem like a good idea. You should prefix the macro with GWP_ if you're concerned about name clashes.

compiler-rt/lib/gwp_asan/mutex.h

43

You want __atomic_always_lock_free, it'll always be a constexpr (whereas the other can be a libcall).

[cryptoad]

In D61923#1502337, @eugenis wrote:

I think the idea is that implementing our own spinlock is not much harder than having 3 platform-specific implementations (posix, window, fuchsia).
Also, scudo_standalone is doing the same ( @cryptoad, why? ).

As Mitch mentioned, we should move the implementation into a common directory. Why not do this now?

Is the question why do Scudo has its own as opposed to rely on platform specific ones?

[hctim]

In D61923#1502988, @cryptoad wrote:

Is the question why do Scudo has its own as opposed to rely on platform specific ones?

Yes, I have assumptions about why, but would love to hear right from the horse's mouth :)

In D61923#1502404, @jfb wrote:

We can't use std::mutex as we must be C-compatible

Can you clarify what you mean by this? I don't understand.
Have you asked on libcxx-dev? Is there interest in the libc++ community for a stand-alone base?

Sorry, poor choice of wording. Our archive must be able to be statically linked into the supporting allocators. At this stage, the plans are to implement GWP-ASan into Scudo and Android's bionic libc. This means we have to be compatible with the the most restrictive aspects of each allocator's build environment, simultaneously.

In practice, we can't use std::mutex because Scudo specifies -nostdlib++ -nodefaultlibs, and if any part of the implementation of std::mutex (and likewise mtx_t) falls outside of the header file, we will fail to link (as is the case with libc++).

We also are trying to stay independent of pthread for platform-independentness.

The code I see is clearly not platform independent. Please clarify your reasoning. I can understand if you don't want pthread for a valid reason, but "platform-independence" doesn't make sense here.

My view was that small stubs to implement the architecture-dependent and OS-dependent functionality is much easier to manage. If we use pthread on unix, and CreateMutex on Windows, we still have to have OS-dependent ifdefs, but we then pass on the requirement to the supporting allocator to ensure our dependencies are there (which could be a huge pain point both for Scudo+fuchsia and Android).

We also can't use a sanitizer_common variant as we don't want to pull in the entirety sanitizer_common as a dependency.

What's the restriction that makes it unacceptable?

Scudo (standalone) can't pull in the entirety of sanitizer_common (code size + maintainability for fuchsia). It's also a much easier track to get Android supported if we don't have to pull in and build the entirety of sanitizer_common.

Basically, the roadmap is to create a shared mutex library for sanitizer_common, gwp_asan and scudo to all use.

I'm asking all these question because they should be in the commit message, and would hopefully have surfaced from the RFC about GWP / Scudo. If those weren't in the RFC that's fine, they should still be in the commit message and you'll want to update the RFC with "while reviewing code we realized *stuff*".

Ack.

I think the idea is that implementing our own spinlock is not much harder than having 3 platform-specific implementations (posix, window, fuchsia).

Your concerns are backwards. Implementation is a one-time thing, maintenance is an ongoing concern and it way overshadows implementation concerns. In particular, a variety of multicore code that does its own locking is much harder to tune at the system-wide level compared to a single thing that's tuned for each application. I'm not saying a separate mutex doesn't make sense, what I'm saying is that experience shows your above reasoning to be generally invalid. I'm totally willing to believe that there's a very good reason to have your own mutex here, but you gotta explain it.

Hopefully above helps to clarify :)

[jfb]

In D61923#1502404, @jfb wrote:

We can't use std::mutex as we must be C-compatible

Can you clarify what you mean by this? I don't understand.
Have you asked on libcxx-dev? Is there interest in the libc++ community for a stand-alone base?

Sorry, poor choice of wording. Our archive must be able to be statically linked into the supporting allocators. At this stage, the plans are to implement GWP-ASan into Scudo and Android's bionic libc. This means we have to be compatible with the the most restrictive aspects of each allocator's build environment, simultaneously.

In practice, we can't use std::mutex because Scudo specifies -nostdlib++ -nodefaultlibs, and if any part of the implementation of std::mutex (and likewise mtx_t) falls outside of the header file, we will fail to link (as is the case with libc++).

Have you asked on libcxx-dev whether a stand-alone base is something of interest to them?

We also are trying to stay independent of pthread for platform-independentness.

The code I see is clearly not platform independent. Please clarify your reasoning. I can understand if you don't want pthread for a valid reason, but "platform-independence" doesn't make sense here.

My view was that small stubs to implement the architecture-dependent and OS-dependent functionality is much easier to manage. If we use pthread on unix, and CreateMutex on Windows, we still have to have OS-dependent ifdefs, but we then pass on the requirement to the supporting allocator to ensure our dependencies are there (which could be a huge pain point both for Scudo+fuchsia and Android).

We also can't use a sanitizer_common variant as we don't want to pull in the entirety sanitizer_common as a dependency.

What's the restriction that makes it unacceptable?

Scudo (standalone) can't pull in the entirety of sanitizer_common (code size + maintainability for fuchsia). It's also a much easier track to get Android supported if we don't have to pull in and build the entirety of sanitizer_common.

Basically, the roadmap is to create a shared mutex library for sanitizer_common, gwp_asan and scudo to all use.

I'm asking all these question because they should be in the commit message, and would hopefully have surfaced from the RFC about GWP / Scudo. If those weren't in the RFC that's fine, they should still be in the commit message and you'll want to update the RFC with "while reviewing code we realized *stuff*".

Ack.

I think the idea is that implementing our own spinlock is not much harder than having 3 platform-specific implementations (posix, window, fuchsia).

Your concerns are backwards. Implementation is a one-time thing, maintenance is an ongoing concern and it way overshadows implementation concerns. In particular, a variety of multicore code that does its own locking is much harder to tune at the system-wide level compared to a single thing that's tuned for each application. I'm not saying a separate mutex doesn't make sense, what I'm saying is that experience shows your above reasoning to be generally invalid. I'm totally willing to believe that there's a very good reason to have your own mutex here, but you gotta explain it.

Hopefully above helps to clarify :)

Kinda... but your answer really sounds like this is a Google-only project, with intended uses only for some Google applications. That's not necessarily a bad thing, but it's really weird: my impression was that GWP and Scudo were intended to be generally usable elsewhere. Is that not the case?

Not that I expect *you* to do any porting work, but the direction you're setting just sounds like "well, we're our only users and we'll take the path that'll work for us". None of the reasoning seems to be truly technical, it's more "these projects we want to integrate into build this way, so we should fit in that way". i.e. it's more about implementation convenience than anything else. Is that the case? Implementation convenience is sometimes a good reason, but as I've outlined above I think you need to provide more thoughtful reasoning.

[hctim]

In D61923#1503272, @jfb wrote:

Have you asked on libcxx-dev whether a stand-alone base is something of interest to them?

No, but I will follow up on that.

Kinda... but your answer really sounds like this is a Google-only project, with intended uses only for some Google applications. That's not necessarily a bad thing, but it's really weird: my impression was that GWP and Scudo were intended to be generally usable elsewhere. Is that not the case?

Not that I expect *you* to do any porting work, but the direction you're setting just sounds like "well, we're our only users and we'll take the path that'll work for us". None of the reasoning seems to be truly technical, it's more "these projects we want to integrate into build this way, so we should fit in that way". i.e. it's more about implementation convenience than anything else. Is that the case? Implementation convenience is sometimes a good reason, but as I've outlined above I think you need to provide more thoughtful reasoning.

I definitely don't want that to be the case, or to have it come across that way. We want a reference implementation that's available for any allocator to drop in and use, with minor tweaking. As part of that, our goal is to make the requirements to support GWP-ASan as low as possible, preferably as simple as "merge this into your codebase somewhere, and you're good to go". We inherit the restrictions of each allocator's build system, which means more restrictive environment for us, but we can be drop-in supported pretty much everywhere. Our plans for this reference implementation is to use it in Android and Fuchsia, but we would love to collaborate with other interested projects to hear about what their requirements would be as well.

We discussed at length whether to have GWP-ASan be a standalone GitHub project (similar to Scudo standalone), or as part of compiler-rt. We decided to put it into compiler-rt because we can then exercise LLVM's extensive build/test/review infrastructure and open-source licensing.

[hctim]

Merged in master after fixing up some buildbots with the previous patches.

Also have pinged libcxx-dev :)

[hctim]

Changed GWP-ASan to use platform specific mutexes. For now, we only
target Android and Linux, and subsequently only need the pthread_mutex
variant for POSIX.

Kept around the mutex unittests as it's an easy assertion that the
abstraction over the platform specifics is implemented correctly.

[eugenis]

compiler-rt/lib/gwp_asan/mutex.h

28

What's the point of this include? You are leaking platform details into this common header anyway.

We can make the interface C-only; or use pImpl to hide the implementation; or just move the entire declaration of Mutex to the platform header.

[hctim]

• Updated to use pointer-to-impl to abstract implementation behaviour away from header files.

[eugenis]

compiler-rt/lib/gwp_asan/platform_specific/mutex_posix.cpp

43 ↗

(On Diff #200604)

This is a dependency on libc++ / libstdc++.

I'm not sure about using malloc() inside mutex constructor, either.

We will probably want the mutex to be linker-initialized, too. AFAIK, gwp-asan would not have any clear initialization entry point, and would need to do this lazily in malloc, which can there be several of, concurrently.

[hctim]

• Ifdef-d headers into mutex.h

compiler-rt/lib/gwp_asan/platform_specific/mutex_posix.cpp

43 ↗

(On Diff #200604)

As per offline discussion, have ifdef-d the platform-specific headers into this file. Allows us to have linker initialisation (at least for POSIX).

[morehouse]

compiler-rt/lib/gwp_asan/mutex.h

23

We should probably delete copy constructor and operator=

41

We should also delete operator=.

compiler-rt/lib/gwp_asan/platform_specific/mutex_posix.cpp

19 ↗

(On Diff #200760)

Unnecessary parens (also below)

compiler-rt/lib/gwp_asan/tests/driver.cpp

15

Can we just link with gtest_main instead of having this?

compiler-rt/lib/gwp_asan/tests/mutex_test.cpp

21

Nit: ConstructionTest doesn't seem to describe what this test does.

Something like LockUnlockTest seems more descriptive.

(Same for other "Construction" tests)

38

We should trylock inside the scope, and maybe also do an unlock+lock.

44

This doesn't need to be a global.

45

static

46

Can we use the simpler syntax while (!StartingGun) instead?

47

Format seems weird. Does clang-format let us do while (...) {} on one line?

50

Nit: curly braces unnecessary

60

Can we use simpler StartingGun = true?

69

static

83

I don't think we should care about the number of cores at all. Time-sliced threads are just fine for this test.

102

How are any of these "thrash" tests?

I'd prefer something more descriptive, like SynchronizedCounterTest.

103

This test case seems to test a superset of ThreadedConstructionTest, so do we really need that one?

105

4 threads isn't very much. Can we test with more threads, say ~1000?

compiler-rt/test/gwp_asan/CMakeLists.txt

2

Can the lit test stuff go in another patch when we actually have tests?

[hctim]

• Apologies about the delay on this. Updated with Matt's comments.

compiler-rt/lib/gwp_asan/tests/driver.cpp

15

Unfortunately not easily. generate_compiler_rt_tests builds each test cpp file individually, and provides no way to add gtest_main only during link time.

compiler-rt/lib/gwp_asan/tests/mutex_test.cpp

47

CF changes it to

while (!StartingGun) {
}

compiler-rt/test/gwp_asan/CMakeLists.txt

2

Not AFAIK. The unit tests are actually invoked through the lit configurations in this directory.

[morehouse]

compiler-rt/lib/gwp_asan/tests/driver.cpp

15

Then how does this driver.cpp get included in each unit test?

Maybe we should put the main in each test as is usually done.

compiler-rt/lib/gwp_asan/tests/mutex_test.cpp

38

No, I didn't mean that way.

Something like this:

{
  ScopedLock L(Mu);
  EXPECT_FALSE(Mu.tryLock());  // Test that the ctor did in fact lock
  Mu.unlock()
  EXPECT_TRUE(Mu.tryLock());  // Test that manual unlock overrides ScopedLock
}
EXPECT_TRUE(Mu.tryLock());  // Test that dtor did in fact unlock

47

Not a big deal, but might be more readable if we do:

while (!StartingGun) {
  // Wait for starting gun.
}

60

Can we use simpler StartingGun = true?

103

This test case seems to test a superset of ThreadedConstructionTest, so do we really need that one?

[hctim]

• Updated from Matt's comments.

compiler-rt/lib/gwp_asan/tests/driver.cpp

15

Basically what happens:

for x in *.cpp;
  do clang++ $x -o $x.o
done
clang++ *.o -o GwpAsanUnitTests

The unittests are all packaged together into a single binary. Also, AFAIK, compiler-rt all has a single main() driver for unittests (at least ASan+MSan+Scudo do this).

compiler-rt/lib/gwp_asan/tests/mutex_test.cpp

103

Deleted ThreadedLockUnlockTest.

[morehouse]

LGTM

[hctim]

Merged with tip-of-tree in preparation for submit.

[hctim]

Looks like this broke an autoconf bot. Have submitted rL362149, which should hopefully fix the issue.

[hctim]

Looks like this also broke an armv8 bot, due to a maximum number of threads issue. Have filed rL362163 to attempt to fix. If that doesn't work, I'll just disable the test for armv8.

clang/runtime/CMakeLists.txt

if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND EXISTS ${COMPILER_RT_SRC_ROOT}/)
   if(LLVM_INCLUDE_TESTS)
     # Add binaries that compiler-rt tests depend on.
     set(COMPILER_RT_TEST_DEPENDENCIES
       FileCheck count not llvm-nm llvm-objdump llvm-symbolizer)
 
     # Add top-level targets for various compiler-rt test suites.
     set(COMPILER_RT_TEST_SUITES check-fuzzer check-asan check-hwasan check-asan-dynamic check-dfsan
       check-lsan check-msan check-sanitizer check-tsan check-ubsan check-ubsan-minimal
-      check-profile check-cfi check-cfi-and-supported check-safestack)
+      check-profile check-cfi check-cfi-and-supported check-safestack check-gwp_asan)
     foreach(test_suite ${COMPILER_RT_TEST_SUITES})
       get_ext_project_build_command(run_test_suite ${test_suite})
       add_custom_target(${test_suite}
         COMMAND ${run_test_suite}
         DEPENDS compiler-rt-build ${COMPILER_RT_TEST_DEPENDENCIES}
         WORKING_DIRECTORY ${BINARY_DIR}
         VERBATIM
         USES_TERMINAL

compiler-rt/lib/gwp_asan/CMakeLists.txt

 add_compiler_rt_component(gwp_asan)
 
 include_directories(..)
 
 set(GWP_ASAN_SOURCES
   random.cpp
 )
 
 set(GWP_ASAN_HEADERS
+  definitions.h
+  mutex.h
   random.h
 )
 
 # Disable RTTI and exception support, as we want these libraries to be
 # C-compatible. Regular C source files can be linked against the generated
 # GwpAsan libraries using the Clang C compiler.
 set(GWP_ASAN_CFLAGS -fno-rtti -fno-exceptions)
 
if (COMPILER_RT_HAS_GWP_ASAN)
   endforeach()
 
   add_compiler_rt_object_libraries(RTGwpAsan
       ARCHS ${GWP_ASAN_SUPPORTED_ARCH}
       SOURCES ${GWP_ASAN_SOURCES}
       ADDITIONAL_HEADERS ${GWP_ASAN_HEADERS}
       CFLAGS ${GWP_ASAN_CFLAGS})
 endif()
+
+if(COMPILER_RT_INCLUDE_TESTS)
+  add_subdirectory(tests)
+endif()

compiler-rt/lib/gwp_asan/definitions.h

+//===-- gwp_asan_definitions.h ----------------------------------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef GWP_ASAN_DEFINITIONS_H_
+#define GWP_ASAN_DEFINITIONS_H_
+
+#define ALWAYS_INLINE inline __attribute__((always_inline))
+
+#endif // GWP_ASAN_DEFINITIONS_H_

compiler-rt/lib/gwp_asan/mutex.h

+//===-- mutex.h -------------------------------------------------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// TODO(hctim): Move this implementation and Scudo's implementation into a
+// unified base implementation. We shouldn't need to have separate
+// implementations for this.
+
+#ifndef GWP_ASAN_MUTEX_H_
+#define GWP_ASAN_MUTEX_H_
+
+#include "gwp_asan/definitions.h"
+
+#include <cstdint>
+
+#ifdef __unix__
+#include <sched.h>
+#endif // defined(__unix__)
+
+namespace gwp_asan {
+class Mutex {
+public:
+  void lock();
+  bool tryLock();
+  void unlock();
+
+private:
+  // How many cycles do we yield on the processor per call to yieldProcessor().
+  static constexpr unsigned kProcessorYieldCount = 10;
+  void yieldProcessor();
+  void yieldPlatform();
+
+  void lockSlow();
+
+  bool Locked = false;
+  static_assert(
+      __atomic_always_lock_free(sizeof(Locked), /*Typical Alignment*/ 0),
+      "gwp_asan::Mutex::Locked is not lock-free on this architecture.");
+};
+
+class ScopedLock {
+public:
+  explicit ScopedLock(Mutex &Mx) : Mu(Mx) { Mu.lock(); }
+  ~ScopedLock() { Mu.unlock(); }
+  ScopedLock(const ScopedLock &) = delete;
+
+private:
+  Mutex &Mu;
+};
+
+ALWAYS_INLINE void Mutex::lock() {
+  if (tryLock())
+    return;
+  lockSlow();
+}
+
+ALWAYS_INLINE bool Mutex::tryLock() {
+  return !__atomic_exchange_n(&Locked, true, __ATOMIC_ACQUIRE);
+}
+
+ALWAYS_INLINE void Mutex::unlock() {
+  __atomic_store_n(&Locked, false, __ATOMIC_RELEASE);
+}
+
+ALWAYS_INLINE void Mutex::yieldProcessor() {
+  __atomic_signal_fence(__ATOMIC_SEQ_CST);
+#if defined(__i386__) || defined(__x86_64__)
+  for (unsigned i = 0; i < kProcessorYieldCount; ++i)
+    asm volatile("pause");
+#elif defined(__aarch64__) || defined(__arm__)
+  for (unsigned i = 0; i < kProcessorYieldCount; ++i)
+    asm volatile("yield");
+#else
+#error "GWP-ASan on this architecture is not supported."
+#endif
+  __atomic_signal_fence(__ATOMIC_SEQ_CST);
+}
+
+ALWAYS_INLINE void Mutex::lockSlow() {
+  for (uint32_t i = 0;; ++i) {
+    if (i < 10)
+      yieldProcessor();
+    else
+      yieldPlatform();
+
+    if (!__atomic_load_n(&Locked, __ATOMIC_RELAXED) && tryLock())
+      return;
+  }
+}
+
+#ifdef __unix__
+ALWAYS_INLINE void Mutex::yieldPlatform() { sched_yield(); }
+#else
+#error "GWP-ASan on this platform is not supported."
+#endif
+
+} // namespace gwp_asan
+
+#endif // GWP_ASAN_MUTEX_H_

compiler-rt/lib/gwp_asan/tests/CMakeLists.txt

+include(CompilerRTCompile)
+
+set(GWP_ASAN_UNITTEST_CFLAGS
+  ${COMPILER_RT_UNITTEST_CFLAGS}
+  ${COMPILER_RT_GTEST_CFLAGS}
+  -I${COMPILER_RT_SOURCE_DIR}/lib/
+  -O2)
+
+file(GLOB GWP_ASAN_HEADERS ../*.h)
+file(GLOB GWP_ASAN_UNITTESTS *.cpp)
+set(GWP_ASAN_UNIT_TEST_HEADERS
+  ${GWP_ASAN_HEADERS})
+
+add_custom_target(GwpAsanUnitTests)
+set_target_properties(GwpAsanUnitTests PROPERTIES FOLDER "Compiler-RT Tests")
+
+set(GWP_ASAN_UNITTEST_LINK_FLAGS ${COMPILER_RT_UNITTEST_LINK_FLAGS})
+list(APPEND GWP_ASAN_UNITTEST_LINK_FLAGS --driver-mode=g++)
+if(NOT WIN32)
+  list(APPEND GWP_ASAN_UNITTEST_LINK_FLAGS -lpthread)
+endif()
+
+if(COMPILER_RT_DEFAULT_TARGET_ARCH IN_LIST GWP_ASAN_SUPPORTED_ARCH)
+  # GWP-ASan unit tests are only run on the host machine.
+  set(arch ${COMPILER_RT_DEFAULT_TARGET_ARCH})
+
+  set(GWP_ASAN_TEST_RUNTIME RTGwpAsanTest.${arch})
+
+  set(GWP_ASAN_TEST_RUNTIME_OBJECTS
+    $<TARGET_OBJECTS:RTGwpAsan.${arch}>)
+
+  add_library(${GWP_ASAN_TEST_RUNTIME} STATIC
+    ${GWP_ASAN_TEST_RUNTIME_OBJECTS})
+
+  set_target_properties(${GWP_ASAN_TEST_RUNTIME} PROPERTIES
+    ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
+    FOLDER "Compiler-RT Runtime tests")
+
+  set(GwpAsanTestObjects)
+  generate_compiler_rt_tests(GwpAsanTestObjects
+    GwpAsanUnitTests "GwpAsan-${arch}-Test" ${arch}
+    SOURCES ${GWP_ASAN_UNITTESTS} ${COMPILER_RT_GTEST_SOURCE}
+    RUNTIME ${GWP_ASAN_TEST_RUNTIME}
+    DEPS gtest ${GWP_ASAN_UNIT_TEST_HEADERS}
+    CFLAGS ${GWP_ASAN_UNITTEST_CFLAGS}
+    LINK_FLAGS ${GWP_ASAN_UNITTEST_LINK_FLAGS})
+  set_target_properties(GwpAsanUnitTests PROPERTIES
+    RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
+endif()

compiler-rt/lib/gwp_asan/tests/driver.cpp

+//===-- driver.cc -----------------------------------------------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "gtest/gtest.h"
+
+int main(int argc, char **argv) {
+  testing::InitGoogleTest(&argc, argv);
+  return RUN_ALL_TESTS();
+}

compiler-rt/lib/gwp_asan/tests/mutex_test.cpp

+//===-- mutex_test.cpp ------------------------------------------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "gwp_asan/mutex.h"
+#include "gtest/gtest.h"
+
+#include <atomic>
+#include <mutex>
+#include <thread>
+#include <vector>
+
+using gwp_asan::Mutex;
+using gwp_asan::ScopedLock;
+
+TEST(GwpAsanMutexTest, ConstructionTest) {
+  Mutex Mu;
+
+  ASSERT_TRUE(Mu.tryLock());
+  ASSERT_FALSE(Mu.tryLock());
+  Mu.unlock();
+
+  Mu.lock();
+  Mu.unlock();
+
+  // Ensure that the mutex actually unlocked.
+  ASSERT_TRUE(Mu.tryLock());
+  Mu.unlock();
+}
+
+TEST(GwpAsanMutexTest, ScopedConstructionTest) {
+  Mutex Mu;
+  { ScopedLock L(Mu); }
+  // Locking will fail here if the scoped lock failed to unlock.
+  EXPECT_TRUE(Mu.tryLock());
+  Mu.unlock();
+}
+
+static constexpr unsigned kNumLocksInARow = 1000;
+void lockTask(std::atomic<bool> *StartingGun, Mutex *Mu) {
+  while (!StartingGun->load())
+    ;
+  for (unsigned i = 0; i < kNumLocksInARow; ++i) {
+    ScopedLock L(*Mu);
+  }
+}
+
+TEST(GwpAsanMutexTest, ThreadedConstructionTest) {
+  Mutex Mu;
+  std::atomic<bool> StartingGun{false};
+
+  std::thread T1(lockTask, &StartingGun, &Mu);
+  std::thread T2(lockTask, &StartingGun, &Mu);
+
+  StartingGun.store(true);
+  T1.join();
+  T2.join();
+
+  // Locking will fail here if the scoped lock failed to unlock.
+  EXPECT_TRUE(Mu.tryLock());
+  Mu.unlock();
+}
+
+void thrashTask(std::atomic<bool> *StartingGun, Mutex *Mu, unsigned *Counter,
+                unsigned NumIterations) {
+  while (!StartingGun->load())
+    ;
+  for (unsigned i = 0; i < NumIterations; ++i) {
+    ScopedLock L(*Mu);
+    (*Counter)++;
+  }
+}
+
+void runThrashTest(unsigned NumThreads, unsigned CounterMax) {
+  std::vector<std::thread> Threads;
+  if (std::thread::hardware_concurrency() < NumThreads) {
+    NumThreads = std::thread::hardware_concurrency();
+  }
+
+  ASSERT_TRUE(CounterMax % NumThreads == 0);
+
+  std::atomic<bool> StartingGun{false};
+  Mutex Mu;
+  unsigned Counter = 0;
+
+  for (unsigned i = 0; i < NumThreads; ++i)
+    Threads.emplace_back(thrashTask, &StartingGun, &Mu, &Counter,
+                         CounterMax / NumThreads);
+
+  StartingGun.store(true);
+  for (auto &T : Threads)
+    T.join();
+
+  EXPECT_EQ(CounterMax, Counter);
+}
+
+TEST(GwpAsanMutexTest, ThrashTests) {
+  runThrashTest(2, 10000);
+  runThrashTest(4, 10000);
+  runThrashTest(4, 100000);
+}

compiler-rt/test/gwp_asan/CMakeLists.txt

+set(GWP_ASAN_LIT_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
+set(GWP_ASAN_LIT_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
+
+set(GWP_ASAN_TESTSUITES)
+
+set(GWP_ASAN_UNITTEST_DEPS)
+set(GWP_ASAN_TEST_DEPS
+  ${SANITIZER_COMMON_LIT_TEST_DEPS}
+  gwp_asan)
+
+if (COMPILER_RT_INCLUDE_TESTS)
+  list(APPEND GWP_ASAN_TEST_DEPS GwpAsanUnitTests)
+  configure_lit_site_cfg(
+    ${CMAKE_CURRENT_SOURCE_DIR}/unit/lit.site.cfg.in
+    ${CMAKE_CURRENT_BINARY_DIR}/unit/lit.site.cfg)
+  add_lit_testsuite(check-gwp_asan-unit "Running GWP-ASan unit tests"
+    ${CMAKE_CURRENT_BINARY_DIR}/unit
+    DEPENDS ${GWP_ASAN_TEST_DEPS})
+  set_target_properties(check-gwp_asan-unit PROPERTIES FOLDER
+    "Compiler-RT Tests")
+    list(APPEND GWP_ASAN_TEST_DEPS check-gwp_asan-unit)
+endif()
+
+configure_lit_site_cfg(
+  ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
+  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
+  )
+
+foreach(arch ${GWP_ASAN_SUPPORTED_ARCH})
+  set(GWP_ASAN_TEST_TARGET_ARCH ${arch})
+  string(TOLOWER "-${arch}" GWP_ASAN_TEST_CONFIG_SUFFIX)
+  get_test_cc_for_arch(${arch} GWP_ASAN_TEST_TARGET_CC GWP_ASAN_TEST_TARGET_CFLAGS)
+  string(TOUPPER ${arch} ARCH_UPPER_CASE)
+  set(CONFIG_NAME ${ARCH_UPPER_CASE}${OS_NAME}Config)
+
+  configure_lit_site_cfg(
+    ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
+    ${CMAKE_CURRENT_BINARY_DIR}/${CONFIG_NAME}/lit.site.cfg)
+  list(APPEND GWP_ASAN_TESTSUITES ${CMAKE_CURRENT_BINARY_DIR}/${CONFIG_NAME})
+endforeach()
+
+add_lit_testsuite(check-gwp_asan "Running the GWP-ASan tests"
+  ${GWP_ASAN_TESTSUITES}
+  DEPENDS ${GWP_ASAN_TEST_DEPS})
+set_target_properties(check-gwp_asan PROPERTIES FOLDER "Compiler-RT Misc")

compiler-rt/test/gwp_asan/dummy_test.cc

+// Exists to simply stop warnings about lit not discovering any tests here.
+// RUN: %clang %s
+
+int main() { return 0; }

compiler-rt/test/gwp_asan/lit.cfg

+# -*- Python -*-
+
+import os
+
+# Setup config name.
+config.name = 'GWP-ASan' + config.name_suffix
+
+# Setup source root.
+config.test_source_root = os.path.dirname(__file__)
+
+# Test suffixes.
+config.suffixes = ['.c', '.cc', '.cpp', '.test']
+
+# C & CXX flags.
+c_flags = ([config.target_cflags])
+
+# Android doesn't want -lrt.
+if not config.android:
+  c_flags += ["-lrt"]
+
+cxx_flags = (c_flags + config.cxx_mode_flags + ["-std=c++11"])
+
+def build_invocation(compile_flags):
+  return " " + " ".join([config.clang] + compile_flags) + " "
+
+# Add substitutions.
+config.substitutions.append(("%clang ", build_invocation(c_flags)))
+
+# GWP-ASan tests are currently supported on Linux only.
+if config.host_os not in ['Linux']:
+   config.unsupported = True

compiler-rt/test/gwp_asan/lit.site.cfg.in

+@LIT_SITE_CFG_IN_HEADER@
+
+config.name_suffix = "@GWP_ASAN_TEST_CONFIG_SUFFIX@"
+config.target_arch = "@GWP_ASAN_TEST_TARGET_ARCH@"
+config.target_cflags = "@GWP_ASAN_TEST_TARGET_CFLAGS@"
+
+# Load common config for all compiler-rt lit tests.
+lit_config.load_config(config, "@COMPILER_RT_BINARY_DIR@/test/lit.common.configured")
+
+# Load tool-specific config that would do the real work.
+lit_config.load_config(config, "@GWP_ASAN_LIT_SOURCE_DIR@/lit.cfg")

compiler-rt/test/gwp_asan/unit/lit.site.cfg.in

+@LIT_SITE_CFG_IN_HEADER@
+
+config.name = "GwpAsan-Unittest"
+# Load common config for all compiler-rt unit tests.
+lit_config.load_config(config, "@COMPILER_RT_BINARY_DIR@/unittests/lit.common.unit.configured")
+
+config.test_exec_root = os.path.join("@COMPILER_RT_BINARY_DIR@",
+                                     "lib", "gwp_asan", "tests")
+config.test_source_root = config.test_exec_root