| Age | Commit message (Collapse) | Author |
|---|
|
Summary:
The low-fat STL-like vector container will be reused in MSan.
It is needed to implement an atexit(3) interceptor on NetBSD/amd64 in MSan.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, dvyukov, eugenis, vitalybuka, kcc
Reviewed By: dvyukov
Subscribers: kubamracek, mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40726
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319650 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
NetBSD cannot spawn new POSIX thread entities in early
libc and libpthread initialization stage. Defer this to the point
of intercepting the first pthread_create(3) call.
This is the last change that makes Thread Sanitizer functional
on NetBSD/amd64 without downstream patches.
********************
Testing Time: 64.91s
********************
Failing Tests (5):
ThreadSanitizer-x86_64 :: dtls.c
ThreadSanitizer-x86_64 :: ignore_lib5.cc
ThreadSanitizer-x86_64 :: ignored-interceptors-mmap.cc
ThreadSanitizer-x86_64 :: mutex_lock_destroyed.cc
ThreadSanitizer-x86_64 :: vfork.cc
Expected Passes : 290
Expected Failures : 1
Unsupported Tests : 83
Unexpected Failures: 5
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, eugenis, dvyukov, vitalybuka
Reviewed By: dvyukov
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40583
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319305 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@317865 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
See the added comment for an explanation.
Reviewed in https://reviews.llvm.org/D37107
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@311768 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
With rL279771, SizeClassAllocator64 was changed to accept only one template
instead of 5, for the following reasons: "First, this will make the mangled
names shorter. Second, this will make adding more parameters simpler". This
patch mirrors that work for SizeClassAllocator32.
This is in preparation for introducing the randomization of chunks in the
32-bit SizeClassAllocator in a later patch.
Reviewers: kcc, alekseyshl, dvyukov
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33141
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@303071 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch allows the Swift compiler to emit calls to `__tsan_external_write` before starting any modifying access, which will cause TSan to detect races on arrays, dictionaries and other classes defined in non-instrumented modules. Races on collections from the Swift standard library and user-defined structs and a frequent cause of subtle bugs and it's important that TSan detects those on top of existing LLVM IR instrumentation, which already detects races in direct memory accesses.
Differential Revision: https://reviews.llvm.org/D31630
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302050 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
For a linker init mutex with lazy flag setup
(no __tsan_mutex_create call), it is possible that
no lock/unlock happened before the destroy call.
Then when destroy runs we still don't know that
it is a linker init mutex and will emulate a memory write.
This in turn can lead to false positives as the mutex
is in fact linker initialized.
Support linker init flag in destroy annotation to resolve this.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@301795 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
To make the TSan external API work with Swift and other use cases, we need to track "tags" for individual memory accesses. Since there is no space to store this information in shadow cells, let's use the thread traces for that. This patch stores the tag as an extra frame in the stack traces (by calling FuncEntry and FuncExit with the address of a registered tag), this extra frame is then stripped before printing the backtrace to stderr.
Differential Revision: https://reviews.llvm.org/D32382
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@301777 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch make sure we don't report deadlocks and other bug types when we're inside an interceptor that was called from a noninstrumented module (when ignore_noninstrumented_modules=1 is set). Adding a testcase that shows that deadlock detection still works on Darwin (to make sure we're not silencing too many reports).
Differential Revision: https://reviews.llvm.org/D31449
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@300998 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We seem to assume that OS-provided thread IDs are either uptr or int, neither of which is true on Darwin. This introduces a tid_t type, which holds a OS-provided thread ID (gettid on Linux, pthread_threadid_np on Darwin, pthread_self on FreeBSD).
Differential Revision: https://reviews.llvm.org/D31774
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@300473 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
There are several problems with the current annotations (AnnotateRWLockCreate and friends):
- they don't fully support deadlock detection (we need a hook _before_ mutex lock)
- they don't support insertion of random artificial delays to perturb execution (again we need a hook _before_ mutex lock)
- they don't support setting extended mutex attributes like read/write reentrancy (only "linker init" was bolted on)
- they don't support setting mutex attributes if a mutex don't have a "constructor" (e.g. static, Java, Go mutexes)
- they don't ignore synchronization inside of lock/unlock operations which leads to slowdown and false negatives
The new annotations solve of the above problems. See tsan_interface.h for the interface specification and comments.
Reviewed in https://reviews.llvm.org/D31093
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@298809 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch allows a non-instrumented library to call into TSan runtime, and tell us about "readonly" and "modifying" accesses to an arbitrary "object" and provide the caller and tag (type of object). This allows TSan to detect violations of API threading contracts where "read-only" methods can be called simulatenously from multiple threads, while modifying methods must be exclusive.
Differential Revision: https://reviews.llvm.org/D28836
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@293885 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When dealing with GCD worker threads, TSan currently prints weird things like "created by thread T-1" and "[failed to restore the stack]" in reports. This patch avoids that and instead prints "Thread T3 (...) is a GCD worker thread".
Differential Revision: https://reviews.llvm.org/D29103
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@293882 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pointer types and allocation stacks of heap pointers
In ASan, we have __asan_locate_address and __asan_get_alloc_stack, which is used in LLDB/Xcode to show the allocation backtrace for a heap memory object. This patch implements the same for TSan.
Differential Revision: https://reviews.llvm.org/D27656
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@290119 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Currently we either define SANITIZER_GO for Go or don't define it at all for C++.
This works fine with preprocessor (ifdef/ifndef/defined), but does not work
for C++ if statements (e.g. if (SANITIZER_GO) {...}). Also this is different
from majority of SANITIZER_FOO macros which are always defined to either 0 or 1.
Always define SANITIZER_GO to either 0 or 1.
This allows to use SANITIZER_GO in expressions and in flag default values.
Also remove kGoMode and kCppMode, which were meant to be used in expressions,
but they are not defined in sanitizer_common code, so SANITIZER_GO become prevalent.
Also convert some preprocessor checks to C++ if's or ternary expressions.
Majority of this change is done mechanically with:
sed "s#ifdef SANITIZER_GO#if SANITIZER_GO#g"
sed "s#ifndef SANITIZER_GO#if \!SANITIZER_GO#g"
sed "s#defined(SANITIZER_GO)#SANITIZER_GO#g"
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@285443 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
under a flag. Set this flag for the scudo allocator, add a test.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@279793 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
parameter instead of 5. First, this will make the mangled names shorter. Second, this will make adding more parameters simpler.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@279771 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Another stack where we try to free sync objects,
but don't have a processors is:
// ResetRange
// __interceptor_munmap
// __deallocate_stack
// start_thread
// clone
Again, it is a latent bug that lead to memory leaks.
Also, increase amount of memory we scan in MetaMap::ResetRange.
Without that the test does not fail, as we fail to free
the sync objects on stack.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@269041 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Current interface assumes that Go calls ProcWire/ProcUnwire
to establish the association between thread and proc.
With the wisdom of hindsight, this interface does not work
very well. I had to sprinkle Go scheduler with wire/unwire
calls, and any mistake leads to hard to debug crashes.
This is not something one wants to maintian.
Fortunately, there is a simpler solution. We can ask Go
runtime as to what is the current Processor, and that
question is very easy to answer on Go side.
Switch to such interface.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@267703 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is reincarnation of http://reviews.llvm.org/D17648 with the bug fix pointed out by Adhemerval (zatrazz).
Currently ThreadState holds both logical state (required for race-detection algorithm, user-visible)
and physical state (various caches, most notably malloc cache). Move physical state in a new
Process entity. Besides just being the right thing from abstraction point of view, this solves several
problems:
Cache everything on P level in Go. Currently we cache on a mix of goroutine and OS thread levels.
This unnecessary increases memory consumption.
Properly handle free operations in Go. Frees are issue by GC which don't have goroutine context.
As the result we could not do anything more than just clearing shadow. For example, we leaked
sync objects and heap block descriptors.
This will allow to get rid of libc malloc in Go (now we have Processor context for internal allocator cache).
This in turn will allow to get rid of dependency on libc entirely.
Potentially we can make Processor per-CPU in C++ mode instead of per-thread, which will
reduce resource consumption.
The distinction between Thread and Processor is currently used only by Go, C++ creates Processor per OS thread,
which is equivalent to the current scheme.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@267678 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch adds a new TSan report type, ReportTypeMutexInvalidAccess, which is triggered when pthread_mutex_lock or pthread_mutex_unlock returns EINVAL (this means the mutex is invalid, uninitialized or already destroyed).
Differential Revision: http://reviews.llvm.org/D18132
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@263641 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Currently, TSan only reports everything in a formatted textual form. The idea behind this patch is to provide a consistent API that can be used to query information contained in a TSan-produced report. User can use these APIs either in a debugger (via a script or directly), or they can use it directly from the process (e.g. in the __tsan_on_report callback). ASan already has a similar API, see http://reviews.llvm.org/D4466.
Differential Revision: http://reviews.llvm.org/D16191
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@263126 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Broke aarch64 and darwin bots.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@262046 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Currently ThreadState holds both logical state (required for race-detection algorithm, user-visible)
and physical state (various caches, most notably malloc cache). Move physical state in a new
Process entity. Besides just being the right thing from abstraction point of view, this solves several
problems:
1. Cache everything on P level in Go. Currently we cache on a mix of goroutine and OS thread levels.
This unnecessary increases memory consumption.
2. Properly handle free operations in Go. Frees are issue by GC which don't have goroutine context.
As the result we could not do anything more than just clearing shadow. For example, we leaked
sync objects and heap block descriptors.
3. This will allow to get rid of libc malloc in Go (now we have Processor context for internal allocator cache).
This in turn will allow to get rid of dependency on libc entirely.
4. Potentially we can make Processor per-CPU in C++ mode instead of per-thread, which will
reduce resource consumption.
The distinction between Thread and Processor is currently used only by Go, C++ creates Processor per OS thread,
which is equivalent to the current scheme.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@262037 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
1. Android doesn't support __thread keyword. So allocate ThreadState
dynamically and store its pointer in one TLS slot provided by Android.
2. On Android, intercepted functions can be called before ThreadState
is initialized. So add test of thr_->is_inited in some places.
3. On Android, intercepted functions can be called after ThreadState
is destroyed. So add a fake dead_thread_state to represent all
destroyed ThreadStates. And that is also why we don't store the pointer
to ThreadState in shadow memory of pthread_self().
Reviewers: kcc, eugenis, dvyukov
Subscribers: kubabrecka, llvm-commits, tberghammer, danalbert, srhines
Differential Revision: http://reviews.llvm.org/D15301
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@257866 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
function aren't called from ScopedInterceptor").
There are some test failures on the Linux buildbots.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@255997 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
called from ScopedInterceptor
Interceptors using ScopedInteceptor should never call into user's code before the ScopedInterceptor is out of scope (and its destructor is called). Let's add a DCHECK to enforce that.
Differential Revision: http://reviews.llvm.org/D15381
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@255996 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch is by Simone Atzeni with portions by Adhemerval Zanella.
This contains the LLVM patches to enable the thread sanitizer for
PPC64, both big- and little-endian. Two different virtual memory
sizes are supported: Old kernels use a 44-bit address space, while
newer kernels require a 46-bit address space.
There are two companion patches that will be added shortly. There is
a Clang patch to actually turn on the use of the thread sanitizer for
PPC64. There is also a patch that I wrote to provide interceptor
support for setjmp/longjmp on PPC64.
Patch discussion at reviews.llvm.org/D12841.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@255057 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch unify the 39 and 42-bit support for AArch64 by using an external
memory read to check the runtime detected VMA and select the better mapping
and transformation. Although slower, this leads to same instrumented binary
to be independent of the kernel.
Along with this change this patch also fix some 42-bit failures with
ALSR disable by increasing the upper high app memory threshold and also
the 42-bit madvise value for non large page set.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@254151 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This implements a "poor man's TLV" to be used for TSan's ThreadState on OS X. Based on the fact that `pthread_self()` is always available and reliable and returns a valid pointer to memory, we'll use the shadow memory of this pointer as a thread-local storage. No user code should ever read/write to this internal libpthread structure, so it's safe to use it for this purpose. We lazily allocate the ThreadState object and store the pointer here.
Differential Revision: http://reviews.llvm.org/D14288
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@252159 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@251920 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@251919 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch moves a few functions from `sanitizer_linux_libcdep.cc` to `sanitizer_posix_libcdep.cc` in order to use them on OS X as well. Plus a few more small build fixes.
This is part of an effort to port TSan to OS X, and it's one the very first steps. Don't expect TSan on OS X to actually work or pass tests at this point.
Differential Revision: http://reviews.llvm.org/D14235
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@251918 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Race deduplication code proved to be a performance bottleneck in the past if suppressions/annotations are used, or just some races left unaddressed. And we still get user complaints about this:
https://groups.google.com/forum/#!topic/thread-sanitizer/hB0WyiTI4e4
ReportRace already has several layers of caching for racy pcs/addresses to make deduplication faster. However, ReportRace still takes a global mutex (ThreadRegistry and ReportMutex) during deduplication and also calls mmap/munmap (which take process-wide semaphore in kernel), this makes deduplication non-scalable.
This patch moves race deduplication outside of global mutexes and also removes all mmap/munmap calls.
As the result, race_stress.cc with 100 threads and 10000 iterations become 30x faster:
before:
real 0m21.673s
user 0m5.932s
sys 0m34.885s
after:
real 0m0.720s
user 0m23.646s
sys 0m1.254s
http://reviews.llvm.org/D12554
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@246758 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch adds support for tsan on aarch64-linux with 42-bit VMA
(current default config for 64K pagesize kernels). The support is
enabled by defining the SANITIZER_AARCH64_VMA to 42 at build time
for both clang/llvm and compiler-rt. The default VMA is 39 bits.
It also enabled tsan for previous supported VMA (39).
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@246330 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch enabled TSAN for aarch64 with 39-bit VMA layout. As defined by
tsan_platform.h the layout used is:
0000 4000 00 - 0200 0000 00: main binary
2000 0000 00 - 4000 0000 00: shadow memory
4000 0000 00 - 5000 0000 00: metainfo
5000 0000 00 - 6000 0000 00: -
6000 0000 00 - 6200 0000 00: traces
6200 0000 00 - 7d00 0000 00: -
7d00 0000 00 - 7e00 0000 00: heap
7e00 0000 00 - 7fff ffff ff: modules and main thread stack
Which gives it about 8GB for main binary, 4GB for heap and 8GB for
modules and main thread stack.
Most of tests are passing, with the exception of:
* ignore_lib0, ignore_lib1, ignore_lib3 due a kernel limitation for
no support to make mmap page non-executable.
* longjmp tests due missing specialized assembly routines.
These tests are xfail for now.
The only tsan issue still showing is:
rtl/TsanRtlTest/Posix.ThreadLocalAccesses
Which still required further investigation. The test is disable for
aarch64 for now.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@244055 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is done by creating a named shared memory region, unlinking it
and setting up a private (i.e. copy-on-write) mapping of that instead
of a regular anonymous mapping. I've experimented with regular
(sparse) files, but they can not be scaled to the size of MSan shadow
mapping, at least on Linux/X86_64 and ext3 fs.
Controlled by a common flag, decorate_proc_maps, disabled by default.
This patch has a few shortcomings:
* not all mappings are annotated, especially in TSan.
* our handling of memset() of shadow via mmap() puts small anonymous
mappings inside larger named mappings, which looks ugly and can, in
theory, hit the mapping number limit.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@238621 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The patch is generated using clang-tidy misc-use-override check.
This command was used:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
-checks='-*,misc-use-override' -header-filter='llvm|clang' -j=32 -fix \
-format
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@234680 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: http://reviews.llvm.org/D8324
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@232381 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The problem is that without SA_RESTORER flag, kernel ignores the handler. So tracer actually did not setup any handler.
Add SA_RESTORER flag when setting up handlers.
Add a test that causes SIGSEGV in stoptheworld callback.
Move SignalContext from asan to sanitizer_common to print better diagnostics about signal in the tracer thread.
http://reviews.llvm.org/D8005
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@230978 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Sagar Thakur
Reviewers: dvyukov, samsonov, petarj, kcc, dsanders.
Subscribers: mohit.bhakkad, Anand.Takale, llvm-commits.
Differential Revision: http://reviews.llvm.org/D6291
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@229972 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Provide defaults for TSAN_COLLECT_STATS and TSAN_NO_HISTORY.
Replace #ifdef directives with #if. This fixes a bug introduced
in r229112, where building TSan runtime with -DTSAN_COLLECT_STATS=0
would still enable stats collection and reporting.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@229581 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@229120 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Go does not use that.
https://code.google.com/p/thread-sanitizer/issues/detail?id=89
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@229115 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Issue 89: Uses a lot of memory for each goroutine
https://code.google.com/p/thread-sanitizer/issues/detail?id=89
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@229112 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
required for mips64 and aarch64 ports
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@226829 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@225111 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@223732 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Return a linked list of AddressInfo objects, instead of using an array of
these objects as an output parameter. This simplifies the code in callers
of this function (especially TSan).
Fix a few memory leaks from internal allocator, when the returned
AddressInfo objects were not properly cleared.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@223145 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@222228 91177308-0d34-0410-b5e6-96231b3b80d8
|
