summaryrefslogtreecommitdiffstats
path: root/compiler-rt
Commit message (Collapse)AuthorAgeFilesLines
...
* [hwasan] implement detection of realloc-after-freeKostya Serebryany2018-08-242-1/+33
| | | | llvm-svn: 340593
* [hwasan] implement detection of double-free (invalid-free)Kostya Serebryany2018-08-244-21/+87
| | | | llvm-svn: 340591
* [sanitizer] Don't call task_for_pid(mach_task_self). NFC.Kuba Mracek2018-08-232-14/+2
| | | | | | | | | | Calling task_for_pid with mach_task_self is just returning mach_task_self anyway, but it also triggers system warnings (task_for_pid is only supposed to be used by high-privileged executables). NFC. rdar://problem/39198248 Differential Revision: https://reviews.llvm.org/D51119 llvm-svn: 340587
* [sanitizer] Change Mmap*NoAccess to return nullptr on errorKostya Kortchinsky2018-08-237-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: `MmapNoAccess` & `MmapFixedNoAccess` return directly the result of `internal_mmap`, as opposed to other Mmap functions that return nullptr. This inconsistency leads to some confusion for the callers, as some check for `~(uptr)0` (`MAP_FAILED`) for failure (while it can fail with `-ENOMEM` for example). Two potential solutions: change the callers, or make the functions return `nullptr` on failure to follow the precedent set by the other functions. The second option looked more appropriate to me. Correct the callers that were wrongly checking for `~(uptr)0` or `MAP_FAILED`. TODO for follow up CLs: - There are a couple of `internal_mmap` calls in XRay that check for MMAP_FAILED as a result as well (cc: @dberris); they should use `internal_iserror`; Reviewers: eugenis, alekseyshl, dberris, kubamracek Reviewed By: alekseyshl Subscribers: kristina, kubamracek, delcypher, #sanitizers, dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D50940 llvm-svn: 340576
* [hwasan] make error reporting look more like in asan, print the memory tag ↵Kostya Serebryany2018-08-223-28/+50
| | | | | | around the buggy access, simplify one test llvm-svn: 340470
* [hwasan] remove stale data fieldKostya Serebryany2018-08-221-1/+0
| | | | llvm-svn: 340442
* [tsan] Adjust setjmp/longjmp handling on Darwin for macOS MojaveKuba Mracek2018-08-216-4/+30
| | | | | | | | | | On macOS Mojave, the OS started using the XOR-by-a-secret-key scheme (same as glibc is alread doing) for storing the SP value in setjmp environment. We need to adjust for that to keep supporting setjmp/longjmp on latest Darwin. The patch is basically doing the same what we're already doing for glibc. rdar://problem/43542596 Differential Revision: https://reviews.llvm.org/D51064 llvm-svn: 340350
* Fixup for r340342: Avoid Block_release'ing the block since we're no longer ↵Kuba Mracek2018-08-211-1/+1
| | | | | | | | making a copy. rdar://problem/42242579 llvm-svn: 340347
* [tsan] Avoid calling Block_copy in the "sync" GCD interceptorsKuba Mracek2018-08-212-4/+35
| | | | | | | | | | The synchronous dispatch functions in GCD (dispatch_sync, dispatch_barrier_sync), don't make a copy of the passed block. To maintain binary compatibility, we should avoid doing that as well in TSan, as there's no reason to do that. The synchronous dispatch functions will not return before the block is actually executed. rdar://problem/42242579 Differential Revision: https://reviews.llvm.org/D50920 llvm-svn: 340342
* SafeStack: Use correct unsafe stack sizesVlad Tsyrklevich2018-08-212-1/+56
| | | | | | | | | | | | | | | | | Summary: When deallocating thread stacks, we use one thread's unsafe stack size to deallocate another thread's unsafe stack; however, the two sizes may differ. Record an unsafe stack's size in the thread stack linked list. Reviewers: pcc, eugenis Reviewed By: eugenis Subscribers: delcypher, llvm-commits, #sanitizers, kcc Differential Revision: https://reviews.llvm.org/D51016 llvm-svn: 340308
* [hwasan] Add a (almost) no-interceptor mode.Evgeniy Stepanov2018-08-2011-185/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The idea behind this change is to allow sanitization of libc. We are prototyping on Bionic, but the tool interface will be general enough (or at least generalizable) to support any other libc. When libc depends on libclang_rt.hwasan, the latter can not interpose libc functions. In fact, majority of interceptors become unnecessary when libc code is instrumented. This change gets rid of most hwasan interceptors and provides interface for libc to notify hwasan about thread creation and destruction events. Some interceptors (pthread_create) are kept under #ifdef to enable testing with uninstrumented libc. They are expressed in terms of the new libc interface. The new cmake switch, COMPILER_RT_HWASAN_WITH_INTERCEPTORS, ON by default, builds testing version of the library with the aforementioned pthread_create interceptor. With the OFF setting, the library becomes more of a libc plugin. Reviewers: vitalybuka, kcc, jfb Subscribers: srhines, kubamracek, mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50922 llvm-svn: 340216
* [sanitizer] Use private futex operations for BlockingMutexKostya Kortchinsky2018-08-201-2/+6
| | | | | | | | | | | | | | | | | | Summary: Use `FUTEX_PRIVATE_FLAG` in conjunction with the wait & wake operations employed by `BlockingMutex`. As far as I can tell, the mutexes are process-private, and there is an actual performance benefit at employing the private operations. There should be no downside to switching to it. Reviewers: eugenis, alekseyshl, dvyukov Reviewed By: dvyukov Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D50910 llvm-svn: 340178
* [msan] Remove XFAIL: freebsd from test/msan/tls_reuse.ccFangrui Song2018-08-181-1/+0
| | | | | | This passes now. llvm-svn: 340132
* [sanitizer] When setting up shadow memory on iOS, fix handling the return ↵Kuba Mracek2018-08-171-2/+2
| | | | | | | | | | value of task_info on older OS versions task_vm_info is a "revisioned" structure, new OS versions add fields to the end, and compatibility is based on the reported size. On older OS versions, min_address/max_address is not filled back. Let's handle that case. Unfortunately, we can't really write a test (as the failure only happens when on a specific OS version). Differential Revision: https://reviews.llvm.org/D50275 llvm-svn: 340058
* [NFC] Some small test updates for Implicit Conversion sanitizer.Roman Lebedev2018-08-174-7/+84
| | | | | | Split off from D50251. llvm-svn: 339996
* [XRay][compiler-rt] Avoid InternalAlloc(...) in Profiling ModeDean Michael Berris2018-08-172-102/+112
| | | | | | | | | | | | | | | | | | | | | | | | Summary: We avoid using dynamic memory allocated with the internal allocator in the profile collection service used by profiling mode. We use aligned storage for globals and in-struct storage of objects we dynamically initialize. We also remove the dependency on `Vector<...>` which also internally uses the dynamic allocator in sanitizer_common (InternalAlloc) in favour of the XRay allocator and segmented array implementation. This change addresses llvm.org/PR38577. Reviewers: eizan Reviewed By: eizan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50782 llvm-svn: 339978
* Revert "[libFuzzer] Use std::discrete_distribution for input selection."Matt Morehouse2018-08-171-4/+7
| | | | | | | This reverts r339973 due to msan.test failing on sanitizer-x86_64-linux-fuzzer bot. llvm-svn: 339976
* [libFuzzer] Use std::discrete_distribution for input selection.Matt Morehouse2018-08-171-7/+4
| | | | | | | | | | | | | | | | | Summary: Since we're casting from double to size_t during input selection, we really want a discrete distribution over size_t rather than a piecewise distribution over doubles. Reviewers: kcc Reviewed By: kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50356 llvm-svn: 339973
* Revert "Revert "[hwasan] Add __hwasan_handle_longjmp.""Evgeniy Stepanov2018-08-165-7/+76
| | | | | | | | | | | This reapplies commit r339935 with the following changes: * make longjmp test C, not C++, to avoid dependency on libc++/libstdc++ * untag pointer in memset interceptor x86_64 does not have TBI, so hwasan barely works there. Tests must be carefully written in a way that does not leak tagged pointer to system libraries. llvm-svn: 339963
* Revert "[hwasan] Add __hwasan_handle_longjmp."Evgeniy Stepanov2018-08-164-56/+0
| | | | | | This reverts commit 339935 which breaks hwasan tests on x86_64. llvm-svn: 339957
* [hwasan] Enable Android logging.Evgeniy Stepanov2018-08-161-0/+3
| | | | | | | | | | | | Summary: Enable syslog as soon as the shadow is mapped. Reviewers: vitalybuka, kcc Subscribers: srhines, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D50865 llvm-svn: 339950
* [hwasan] Add __hwasan_handle_longjmp.Evgeniy Stepanov2018-08-164-0/+56
| | | | | | | | | | | | | | | | | Summary: A callback to annotate longjmp-like code. Unlike __asan_handle_no_return, in hwasan we can not conservatively "unpoison" the entire thread stack, because there is no such thing as unpoisoned memory. Pointer and memory tags must always match. Reviewers: vitalybuka, kcc Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D50752 llvm-svn: 339935
* [hwasan] Add malloc_fill_byte and free_fill_byte flags.Evgeniy Stepanov2018-08-163-1/+44
| | | | | | | | | | Reviewers: vitalybuka, kcc Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D50753 llvm-svn: 339932
* [Sanitizer] Fix build openbsdDavid Carlier2018-08-161-1/+10
| | | | | | | | | | | | | | - The alternative syscall exists only on FreeBSD. - Adding OpenBSD's equivalent and while at it other remaining oses ones. Reviewers: vitalybuka, krytarowsky, hiraditya Reviewed By: hiraditya Differential Revision: https://reviews.llvm.org/D50760 llvm-svn: 339886
* [XRay][compiler-rt] Remove MAP_NORESERVE from XRay allocationsDean Michael Berris2018-08-162-27/+3
| | | | | | | | | | | | | | | | | | | Summary: This reverses an earlier decision to allow seg-faulting from the XRay-allocated memory if it turns out that the system cannot provide physical memory backing that cannot be swapped in/out on Linux. This addresses http://llvm.org/PR38588. Reviewers: eizan Reviewed By: eizan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50831 llvm-svn: 339869
* cfi: Remove blacklist entries for libc++.Peter Collingbourne2018-08-151-4/+2
| | | | | | | These functions have had no-CFI annotations in the source code for a while now. llvm-svn: 339800
* [hwasan] Add a basic API.Evgeniy Stepanov2018-08-154-3/+56
| | | | | | | | | | | | | | | | Summary: Add user tag manipulation functions: __hwasan_tag_memory __hwasan_tag_pointer __hwasan_print_shadow (very simple and ugly, for now) Reviewers: vitalybuka, kcc Subscribers: kubamracek, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50746 llvm-svn: 339746
* [SanitizerCoverage] Add associated metadata to PC guards.Matt Morehouse2018-08-141-1/+6
| | | | | | | | | | | | | | | | | | | | | | | Summary: Without this metadata LLD strips unused PC table entries but won't strip unused guards. This metadata also seems to influence the linker to change the ordering in the PC guard section to match that of the PC table section. The libFuzzer runtime library depends on the ordering of the PC table and PC guard sections being the same. This is not generally guaranteed, so we may need to redesign PC tables/guards/counters in the future. Reviewers: eugenis Reviewed By: eugenis Subscribers: kcc, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50483 llvm-svn: 339733
* Reland "SafeStack: Delay thread stack clean-up""Vlad Tsyrklevich2018-08-144-29/+89
| | | | | | | | | | This relands commit r339405 (reverted in commit r339408.) The original revert was due to tests failing on a darwin buildbot; however, after looking at the affected code more I realized that the Darwin safestack support has always been broken and disabled it in r339719. This relands the original commit. llvm-svn: 339723
* SafeStack: Disable Darwin supportVlad Tsyrklevich2018-08-143-24/+7
| | | | | | | | | | | | | | | | | Summary: Darwin support does not appear to be used as evidenced by the fact that the pthread interceptors have never worked and there is no support for other common threading mechanisms like GCD. Reviewers: pcc, eugenis, kubamracek Reviewed By: pcc, kubamracek Subscribers: kubamracek, mgorny, delcypher, llvm-commits, #sanitizers, kcc Differential Revision: https://reviews.llvm.org/D50718 llvm-svn: 339719
* [scudo] Fix race condition in deallocation path when Quarantine is bypassedKostya Kortchinsky2018-08-142-5/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There is a race window in the deallocation path when the Quarantine is bypassed. Initially we would just erase the header of a chunk if we were not to use the Quarantine, as opposed to using a compare-exchange primitive, to make things faster. It turned out to be a poor decision, as 2 threads (or more) could simultaneously deallocate the same pointer, and if the checks were to done before the header got erased, this would result in the pointer being added twice (or more) to distinct thread caches, and eventually be reused. Winning the race is not trivial but can happen with enough control over the allocation primitives. The repro added attempts to trigger the bug, with a moderate success rate, but it should be enough to notice if the bug ever make its way back into the code. Since I am changing things in this file, there are 2 smaller changes tagging along, marking a variable `const`, and improving the Quarantine bypass test at runtime. Reviewers: alekseyshl, eugenis, kcc, vitalybuka Reviewed By: eugenis, vitalybuka Subscribers: delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D50655 llvm-svn: 339705
* [CMake] Don't parse target triple except for archPetr Hosek2018-08-142-12/+6
| | | | | | | | | | | | | | compiler-rt CMake build currently tries to parse the triple and then put it back together, but doing so inherently tricky, and doing so from CMake is just crazy and currently doesn't handle triples that have more than three components. Fortunatelly, the CMake really only needs the architecture part, which is typically the first component, to construct variants for other architectures. This means we can keep the rest of the triple as is and avoid the parsing altogether. Differential Revision: https://reviews.llvm.org/D50548 llvm-svn: 339701
* [hwasan] Provide __sanitizer_* aliases to allocator functions.Evgeniy Stepanov2018-08-137-8/+70
| | | | | | | | | | | | | | | | Summary: Export __sanitizer_malloc, etc as aliases to malloc, etc. This way users can wrap sanitizer malloc, even in fully static binaries. Both jemalloc and tcmalloc provide similar aliases (je_* and tc_*). Reviewers: vitalybuka, kcc Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D50570 llvm-svn: 339614
* [hwasan] Handle missing /proc/self/maps.Evgeniy Stepanov2018-08-131-7/+20
| | | | | | | | | | | | | | Summary: Don't crash when /proc/self/maps is inaccessible from main thread. It's not a big deal, really. Reviewers: vitalybuka, kcc Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D50574 llvm-svn: 339607
* [hwasan] Allow optional early shadow setup.Evgeniy Stepanov2018-08-135-13/+42
| | | | | | | | | | | | | | | | Summary: Provide __hwasan_shadow_init that can be used to initialize shadow w/o touching libc. It can be used to bootstrap an unusual case of fully-static executable with hwasan-instrumented libc, which needs to run hwasan code before it is ready to serve user calls like madvise(). Reviewers: vitalybuka, kcc Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D50581 llvm-svn: 339606
* [sanitizer] Remove st(X) from the clobber list in 32-bit x86 atomicsKostya Kortchinsky2018-08-131-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When compiling with `WERROR=ON` & a recent clang, having the `st(?)` registers in the clobber list produces a fatal error (except `st(7)` for some reason): ``` .../sanitizer_common/sanitizer_atomic_clang_x86.h:98:9: error: inline asm clobber list contains reserved registers: ST0, ST1, ST2, ST3, ST4, ST5, ST6 [-Werror,-Winline-asm] "movq %1, %%mm0;" // Use mmx reg for 64-bit atomic moves ^ <inline asm>:1:1: note: instantiated into assembly here movq 8(%esp), %mm0;movq %mm0, (%esi);emms; ^ .../sanitizer_common/sanitizer_atomic_clang_x86.h:98:9: note: Reserved registers on the clobber list may not be preserved across the asm statement, and clobbering them may lead to undefined behaviour. "movq %1, %%mm0;" // Use mmx reg for 64-bit atomic moves ^ <inline asm>:1:1: note: instantiated into assembly here movq 8(%esp), %mm0;movq %mm0, (%esi);emms; ^ ``` As far as I can tell, they were in there due to the use of the `emms` instruction, but removing the clobber doesn't appear to have a functional impact. I am unsure if there is a better way to address this. Reviewers: eugenis, vitalybuka Reviewed By: vitalybuka Subscribers: kubamracek, delcypher, jfb, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D50562 llvm-svn: 339575
* [CMake] Fix bug in `add_weak_symbols()` function.Dan Liew2018-08-131-1/+9
| | | | | | | | | | | | | Previously the the `weak_symbols.txt` files could be modified and the build system wouldn't update the link flags automatically. Instead the developer had to know to reconfigure CMake manually. This is now fixed by telling CMake that the file being used to read weak symbols from is a configure-time dependency. Differential Revision: https://reviews.llvm.org/D50059 llvm-svn: 339559
* [hwasan] Remove liblog dependency.Evgeniy Stepanov2018-08-101-1/+0
| | | | | | | | | | | | | | | | HWASan will not run on older Android releases where we use __android_log_write for logging. This dependency is also harmful in the case when libc itself depends on hwasan, because it creates a loop of libc -> hwasan -> liblog -> libc which makes liblog vs libc initialization order undetermined. Without liblog the loop is just libc -> hwasan -> libc and any init order issues can be solved in hwasan. llvm-svn: 339449
* Revert "SafeStack: Delay thread stack clean-up"Vlad Tsyrklevich2018-08-104-89/+29
| | | | | | | | | This reverts commit r339405, it's failing on Darwin buildbots because it doesn't seem to have a tgkill/thr_kill2 interface. It has a __pthread_kill() syscall, but that relies on having a handle to the thread's port which is not equivalent to it's tid. llvm-svn: 339408
* SafeStack: Delay thread stack clean-upVlad Tsyrklevich2018-08-094-29/+89
| | | | | | | | | | | | | | | | | | Summary: glibc can call SafeStack instrumented code even after the last pthread data destructor has run. Delay cleaning-up unsafe stacks for threads until the thread is dead by having future threads clean-up prior threads stacks. Reviewers: pcc, eugenis Reviewed By: eugenis Subscribers: cryptoad, eugenis, kubamracek, delcypher, llvm-commits, #sanitizers, kcc Differential Revision: https://reviews.llvm.org/D50406 llvm-svn: 339405
* [sanitizer] Remove rsp from the clobber list in internal_cloneKostya Kortchinsky2018-08-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When compiling with WERROR=ON, a new fatal warning started popping up recently (due to -Werror,-Winline-asm): ``` .../lib/sanitizer_common/sanitizer_linux.cc:1214:24: error: inline asm clobber list contains reserved registers: RSP [-Werror,-Winline-asm] "syscall\n" ^ <inline asm>:1:1: note: instantiated into assembly here syscall ^ .../lib/sanitizer_common/sanitizer_linux.cc:1214:24: note: Reserved registers on the clobber list may not be preserved across the asm statement, and clobbering them may lead to undefined behaviour. "syscall\n" ^ <inline asm>:1:1: note: instantiated into assembly here syscall ^ ``` Removing `rsp` from the clobber list makes the warning go away, and does not appear to have a functional impact. If there is another way to solve this, let me know. Reviewers: eugenis, vitalybuka Reviewed By: eugenis Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D50519 llvm-svn: 339370
* Enable getentropy for FreeBSD 12David Carlier2018-08-091-1/+6
| | | | | | | | | | | | As for Linux with its getrandom's syscall, giving the possibility to fill buffer with native call for good quality but falling back to /dev/urandom in worst case similarly. Reviewers: vitalybuka, krytarowski Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D48804 llvm-svn: 339318
* [CMake] Use normalized Windows target triplesPetr Hosek2018-08-0945-45/+45
| | | | | | | | | | | Changes the default Windows target triple returned by GetHostTriple.cmake from the old environment names (which we wanted to move away from) to newer, normalized ones. This also requires updating all tests to use the new systems names in constraints. Differential Revision: https://reviews.llvm.org/D47381 llvm-svn: 339307
* [libFuzzer] Increase the iteration limit in shrink.testGeorge Karpenkov2018-08-091-1/+1
| | | | | | | | | | | | | | After https://reviews.llvm.org/D48800, shrink.test started failing on x86_64h architecture. Looking into this, the optimization pass is too eager to unroll the loop on x86_64h, possibly leading to worse coverage data. Alternative solutions include not unrolling the loop when fuzzing, or disabling this test on that architecture. Differential Revision: https://reviews.llvm.org/D50484 llvm-svn: 339303
* [macOS] stop generating the libclang_rt.10.4.a library for macOS 10.4Alex Lorenz2018-08-082-151/+0
| | | | | | | | The support for macOS 10.4 has been dropped by Xcode 10. rdar://42876880 llvm-svn: 339277
* [libFuzzer] Optimize handle unstable checks by reducing iterationsMax Moroz2018-08-083-16/+21
| | | | | | | | | | | | | | | | | | Summary: We only run the 3rd check if 2nd check finds unstable edges. 3rd UpdateUnstableCounters is now merged with ApplyUnstableCounters to only run 1 iteration. Patch by Kyungtak Woo (@kevinwkt). Reviewers: Dor1s, metzman, morehouse Reviewed By: Dor1s, morehouse Subscribers: delcypher, #sanitizers, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D50411 llvm-svn: 339249
* [Coverage] Ignore 'unused' functions with non-zero execution countsVedant Kumar2018-08-071-0/+53
| | | | | | | | | | | | | | | | | Frontends emit 'unused' coverage mapping records for functions which are provably unused in a TU. These unused records contain a single counter with CounterKind::Zero. However, a function may be unused in one TU and used in another. When this happens, prefer the records with a full set of counters instead of arbitrarily picking the first loaded record. There is no impact on the single-TU case. In the multiple-TU case, this resolves issues causing a function to appear unused when it's not. Testing: check-{llvm,clang,compiler-rt} rdar://42981322 llvm-svn: 339194
* [libFuzzer] Disable print_unstable_stats.test for aarch64.Max Moroz2018-08-071-1/+3
| | | | | | | | | | | | | | | | Summary: Follow-up for https://reviews.llvm.org/D50264. Reported by testbots: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/5592 Reviewers: morehouse, kevinwkt, metzman, javed.absar, Dor1s Reviewed By: Dor1s Subscribers: kristof.beyls, delcypher, #sanitizers, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D50386 llvm-svn: 339143
* [libFuzzer] Add unstable function printing to print_unstable_stats flagMax Moroz2018-08-064-12/+42
| | | | | | | | | | | | | | | | | | | Summary: There may be cases in which a user wants to know which part of their code is unstable. We use ObservedFuncs and UnstableCounters to print at exit which of the ObservedFunctions are unstable under the -print_unstable_stats flag. Patch by Kyungtak Woo (@kevinwkt). Reviewers: Dor1s, metzman, morehouse Reviewed By: Dor1s, metzman, morehouse Subscribers: delcypher, #sanitizers, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D50264 llvm-svn: 339081
* [CMake] Allow building builtins standalone out of tree without any ↵Martin Storsjo2018-08-031-35/+39
| | | | | | | | | | llvm-config available This is the same as libcxxabi/libcxx do. Differential Revision: https://reviews.llvm.org/D50134 llvm-svn: 338818
OpenPOWER on IntegriCloud