summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert r342652 "[winasan] Unpoison the stack in NtTerminateThread"Hans Wennborg2018-09-281-11/+1
| | | | | | | | | | | | | This seems to cause the thread's exit code to be clobbered, breaking Chromium tests. Also revert follow-up r342654. > In long-running builds we've seen some ASan complaints during thread creation that we suspect are due to leftover poisoning from previous threads whose stacks occupied that memory. This patch adds a hook that unpoisons the stack just before the NtTerminateThread syscall. > > Differential Revision: https://reviews.llvm.org/D52091 llvm-svn: 343322
* [XRay] Guard local variables with `static` and struct with unnamed namespacesFangrui Song2018-09-282-6/+11
| | | | | | | | | | | | | | | | | Summary: This is for coding standard conformance, and for fixing an ODR violation issue: __xray::ThreadLocalData is defined twice and differently in xray_fdr_logging.cc and xray_basic_logging.cc Reviewers: dberris, mboerger, eizan Reviewed By: dberris Subscribers: delcypher, jfb, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D52639 llvm-svn: 343289
* [XRay] Add LD_LIBRARY_PATH to env variables for Unit TestsDean Michael Berris2018-09-271-5/+5
| | | | | | | | | | | | | | | | | Summary: This change allows us to use the library path from which the LLVM libraries are installed, in case the LLVM installation generates shared libraries. This should address llvm.org/PR39070. Reviewers: mboerger, eizan Subscribers: mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D52597 llvm-svn: 343280
* [sanitizer] Disable failing Android test after D52371Kostya Kortchinsky2018-09-271-4/+5
| | | | | | | | | | | | | | | | | Summary: The default values used for Space/Size for the new SizeClassMap do not work with Android. The Compact map appears to be in the same boat. Disable the test on Android for now to turn the bots green, but there is no reason Compact & Dense should not have an Android test. Added a FIXME, I will revisit this soon. Reviewers: eugenis Subscribers: srhines, kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D52623 llvm-svn: 343252
* [sanitizer] Introduce a new SizeClassMap with minimal amount of cached entriesKostya Kortchinsky2018-09-272-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: _Note_: I am not attached to the name `DenseSizeClassMap`, so if someone has a better idea, feel free to suggest it. The current pre-defined `SizeClassMap` hold a decent amount of cached entries, either in cheer number of, or in amount of memory cached. Empirical testing shows that more compact per-class arrays (whose sizes are directly correlated to the number of cached entries) are beneficial to performances, particularly in highly threaded environments. The new proposed `SizeClassMap` has the following properties: ``` c00 => s: 0 diff: +0 00% l 0 cached: 0 0; id 0 c01 => s: 16 diff: +16 00% l 4 cached: 8 128; id 1 c02 => s: 32 diff: +16 100% l 5 cached: 8 256; id 2 c03 => s: 48 diff: +16 50% l 5 cached: 8 384; id 3 c04 => s: 64 diff: +16 33% l 6 cached: 8 512; id 4 c05 => s: 80 diff: +16 25% l 6 cached: 8 640; id 5 c06 => s: 96 diff: +16 20% l 6 cached: 8 768; id 6 c07 => s: 112 diff: +16 16% l 6 cached: 8 896; id 7 c08 => s: 128 diff: +16 14% l 7 cached: 8 1024; id 8 c09 => s: 144 diff: +16 12% l 7 cached: 7 1008; id 9 c10 => s: 160 diff: +16 11% l 7 cached: 6 960; id 10 c11 => s: 176 diff: +16 10% l 7 cached: 5 880; id 11 c12 => s: 192 diff: +16 09% l 7 cached: 5 960; id 12 c13 => s: 208 diff: +16 08% l 7 cached: 4 832; id 13 c14 => s: 224 diff: +16 07% l 7 cached: 4 896; id 14 c15 => s: 240 diff: +16 07% l 7 cached: 4 960; id 15 c16 => s: 256 diff: +16 06% l 8 cached: 4 1024; id 16 c17 => s: 320 diff: +64 25% l 8 cached: 3 960; id 49 c18 => s: 384 diff: +64 20% l 8 cached: 2 768; id 50 c19 => s: 448 diff: +64 16% l 8 cached: 2 896; id 51 c20 => s: 512 diff: +64 14% l 9 cached: 2 1024; id 48 c21 => s: 640 diff: +128 25% l 9 cached: 1 640; id 49 c22 => s: 768 diff: +128 20% l 9 cached: 1 768; id 50 c23 => s: 896 diff: +128 16% l 9 cached: 1 896; id 51 c24 => s: 1024 diff: +128 14% l 10 cached: 1 1024; id 48 c25 => s: 1280 diff: +256 25% l 10 cached: 1 1280; id 49 c26 => s: 1536 diff: +256 20% l 10 cached: 1 1536; id 50 c27 => s: 1792 diff: +256 16% l 10 cached: 1 1792; id 51 c28 => s: 2048 diff: +256 14% l 11 cached: 1 2048; id 48 c29 => s: 2560 diff: +512 25% l 11 cached: 1 2560; id 49 c30 => s: 3072 diff: +512 20% l 11 cached: 1 3072; id 50 c31 => s: 3584 diff: +512 16% l 11 cached: 1 3584; id 51 c32 => s: 4096 diff: +512 14% l 12 cached: 1 4096; id 48 c33 => s: 5120 diff: +1024 25% l 12 cached: 1 5120; id 49 c34 => s: 6144 diff: +1024 20% l 12 cached: 1 6144; id 50 c35 => s: 7168 diff: +1024 16% l 12 cached: 1 7168; id 51 c36 => s: 8192 diff: +1024 14% l 13 cached: 1 8192; id 48 c37 => s: 10240 diff: +2048 25% l 13 cached: 1 10240; id 49 c38 => s: 12288 diff: +2048 20% l 13 cached: 1 12288; id 50 c39 => s: 14336 diff: +2048 16% l 13 cached: 1 14336; id 51 c40 => s: 16384 diff: +2048 14% l 14 cached: 1 16384; id 48 c41 => s: 20480 diff: +4096 25% l 14 cached: 1 20480; id 49 c42 => s: 24576 diff: +4096 20% l 14 cached: 1 24576; id 50 c43 => s: 28672 diff: +4096 16% l 14 cached: 1 28672; id 51 c44 => s: 32768 diff: +4096 14% l 15 cached: 1 32768; id 48 c45 => s: 40960 diff: +8192 25% l 15 cached: 1 40960; id 49 c46 => s: 49152 diff: +8192 20% l 15 cached: 1 49152; id 50 c47 => s: 57344 diff: +8192 16% l 15 cached: 1 57344; id 51 c48 => s: 65536 diff: +8192 14% l 16 cached: 1 65536; id 48 c49 => s: 81920 diff: +16384 25% l 16 cached: 1 81920; id 49 c50 => s: 98304 diff: +16384 20% l 16 cached: 1 98304; id 50 c51 => s: 114688 diff: +16384 16% l 16 cached: 1 114688; id 51 c52 => s: 131072 diff: +16384 14% l 17 cached: 1 131072; id 48 c53 => s: 64 diff: +0 00% l 0 cached: 8 512; id 4 Total cached: 864928 (152/432) ``` It holds a bit less of 1MB of cached entries at most, and the cache fits in a page. The plan is to use this map by default for Scudo once we make sure that there is no unforeseen impact for any of current use case. Benchmarks give the most increase in performance (with Scudo) when looking at highly threaded/contentious environments. For example, rcp2-benchmark experiences a 10K QPS increase (~3%), and a decrease of 50MB for the max RSS (~10%). On platforms like Android where we only have a couple of caches, performance remain similar. Reviewers: eugenis, kcc Reviewed By: eugenis Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D52371 llvm-svn: 343246
* [sanitizer] AndroidGetApiLevel for static executables.Evgeniy Stepanov2018-09-261-1/+14
| | | | | | | | | | A version of AndroidGetApiLevel for static executables that is completely compile-time. The generic version uses dl_iterate_phdr which, even though it works in static executables, crashes if called before libc is initialized. llvm-svn: 343153
* [asan] [windows] Don't use CheckFailed in dynamic runtime thunk modeMartin Storsjo2018-09-261-1/+1
| | | | | | | | | | Since SVN r342651, CheckFailed isn't exported from asan-dynamic. See comments in https://reviews.llvm.org/D52279#1246222 for a longer discussion on this issue. Differential Revision: https://reviews.llvm.org/D52566 llvm-svn: 343136
* [winasan] Pin the ASan DLL to prevent unloadingDavid Major2018-09-261-0/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D52505 llvm-svn: 343123
* [CMake] [MinGW] Build address sanitizer for MinGW if building with clangMartin Storsjo2018-09-261-1/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D51885 llvm-svn: 343074
* [ASan] [MinGW] Only try to export MSVC specific C++ symbols if building with ↵Martin Storsjo2018-09-261-1/+1
| | | | | | | | a MSVC like compiler Differential Revision: https://reviews.llvm.org/D51878 llvm-svn: 343073
* Try to fix cosmetics to keep lines below 80 chars. NFC.Martin Storsjo2018-09-251-1/+1
| | | | | | | This should fix following buildbot errors: http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/20371 llvm-svn: 343031
* [Sanitizers] [MinGW] Produce undecorated symbols for /export: directives ↵Martin Storsjo2018-09-251-2/+12
| | | | | | | | | | | | | | | when in MinGW mode In MinGW mode, the /export: directives in object files are interpreted differently; the symbols are not assumed to be decorated. Since the GNU linker doesn't support the /alternatename and /include directives, there's no such distinction for them in lld. This assumes that the resulting sanitizer libraries will be linked by lld. Differential Revision: https://reviews.llvm.org/D51882 llvm-svn: 343015
* [ASan] [Windows] Avoid including windows.h in asan_malloc_win.ccMartin Storsjo2018-09-251-2/+11
| | | | | | | | | | Instead provide manual declarations of the used types, to avoid pulling in conflicting declarations of some of the functions that are to be overridden. Differential Revision: https://reviews.llvm.org/D51914 llvm-svn: 343014
* [Sanitizers] [MinGW] Check for __i386__ in addition to _M_IX86 for i386 ↵Martin Storsjo2018-09-251-4/+4
| | | | | | | | | | | | | | | specific details The MinGW headers do define _M_IX86 (contrary to clang-cl and MSVC where it is a compiler predefined macro), but the headers that define it aren't included here. Also check these defines for setting the symbol prefix, instead of inconsistently using _WIN64 for that. Differential Revision: https://reviews.llvm.org/D51883 llvm-svn: 343013
* [hwasan] Record and display stack history in stack-based reports.Evgeniy Stepanov2018-09-2413-158/+494
| | | | | | | | | | | | | | | | | | | | | Summary: Display a list of recent stack frames (not a stack trace!) when tag-mismatch is detected on a stack address. The implementation uses alignment tricks to get both the address of the history buffer, and the base address of the shadow with a single 8-byte load. See the comment in hwasan_thread_list.h for more details. Developed in collaboration with Kostya Serebryany. Reviewers: kcc Subscribers: srhines, kubamracek, mgorny, hiraditya, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D52249 llvm-svn: 342923
* Revert "[hwasan] Record and display stack history in stack-based reports."Evgeniy Stepanov2018-09-2413-494/+158
| | | | | | This reverts commit r342921: test failures on clang-cmake-arm* bots. llvm-svn: 342922
* [hwasan] Record and display stack history in stack-based reports.Evgeniy Stepanov2018-09-2413-158/+494
| | | | | | | | | | | | | | | | | | | | | Summary: Display a list of recent stack frames (not a stack trace!) when tag-mismatch is detected on a stack address. The implementation uses alignment tricks to get both the address of the history buffer, and the base address of the shadow with a single 8-byte load. See the comment in hwasan_thread_list.h for more details. Developed in collaboration with Kostya Serebryany. Reviewers: kcc Subscribers: srhines, kubamracek, mgorny, hiraditya, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D52249 llvm-svn: 342921
* [compiler-rt] [builtins] Add logb/logbf/logbl methods to compiler-rt to ↵Jordan Rupprecht2018-09-246-10/+77
| | | | | | | | | | | | | | | | | | | | | | | avoid libm dependencies when possible. Summary: The complex division builtins (div?c3) use logb methods from libm to scale numbers during division and avoid rounding issues. However, these come from libm, meaning anyone that uses --rtlib=compiler-rt also has to include -lm. Implement logb* methods for standard ieee 754 floats so we can avoid -lm on those platforms, falling back to the old behavior (using either logb() or `__builtin_logb()`) when not supported. These new methods are defined internally as `__compiler_rt_logb` so as not to conflict with the libm definitions in any way. This fixes just the libm methods mentioned in PR32279 and PR28652. libc is still required, although that seems to not be an issue. Note: this is proposed as an alternative to just adding -lm: D49330. Reviewers: efriedma, compnerd, scanon, echristo Reviewed By: echristo Subscribers: jsji, echristo, nemanjai, dberris, mgorny, kbarton, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D49514 llvm-svn: 342917
* Fix the configuration of the Primary allocator for Darwin ARM64 byDan Liew2018-09-241-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | changing the value of `SANITIZER_MMAP_RANGE_SIZE` to something more sensible. The available VMA is at most 64GiB and not 256TiB that was previously being used. This change gives us several wins: * Drastically improves LeakSanitizer performance on Darwin ARM64 devices. On a simple synthentic benchmark this took leak detection time from ~30 seconds to 0.5 seconds due to the `ForEachChunk(...)` method enumerating a much smaller number of regions. Previously we would pointlessly iterate over a large portion of the SizeClassAllocator32's ByteMap that would could never be set due it being configured for a much larger VM space than is actually availble. * Decreases the memory required for the Primary allocator. Previously the ByteMap inside the the allocator used an array of pointers that took 512KiB of space. Now the required space for the array is 128 bytes. rdar://problem/43509428 Differential Revision: https://reviews.llvm.org/D51173 llvm-svn: 342868
* [XRay] Clean up XRay build configurationDean Michael Berris2018-09-242-16/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change spans both LLVM and compiler-rt, where we do the following: - Add XRay to the LLVMBuild system, to allow for distributing the XRay trace loading library along with the LLVM distributions. - Use `llvm-config` better in the compiler-rt XRay implementation, to depend on the potentially already-distributed LLVM XRay library. While this is tested with the standalone compiler-rt build, it does require that the LLVMXRay library (and LLVMSupport as well) are available during the build. In case the static libraries are available, the unit tests will build and work fine. We're still having issues with attempting to use a shared library version of the LLVMXRay library since the shared library might not be accessible from the standard shared library lookup paths. The larger change here is the inclusion of the LLVMXRay library in the distribution, which allows for building tools around the XRay traces and profiles that the XRay runtime already generates. Reviewers: echristo, beanz Subscribers: mgorny, hiraditya, mboerger, llvm-commits Differential Revision: https://reviews.llvm.org/D52349 llvm-svn: 342859
* [sanitizer] Move __sanitizer_set_death_callback to a more appropriate fileKostya Kortchinsky2018-09-212-5/+9
| | | | | | | | | | | | | | | | | | Summary: `__sanitizer_set_death_callback` is a public interface function wrapping `SetUserDieCallback`. Said function is defined in `sanitizer_termination.cc`, which is not included in all the RT. Moving the interface function to that file allows to not have a spurious public fuinction in RT that don't use it. Reviewers: eugenis Reviewed By: eugenis Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D52363 llvm-svn: 342747
* [XRay][compiler-rt] Update use of internal_mmapDean Michael Berris2018-09-214-36/+41
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The implementation of `internal_mmap(...)` deviates from the contract of `mmap(...)` -- i.e. error returns are actually the equivalent of `errno` results. We update how XRay uses `internal_mmap(...)` to better handle these error conditions. In the process, we change the default pointers we're using from `char*` to `uint8_t*` to prevent potential usage of the pointers in the string library functions that expect to operate on `char*`. We also take the chance to "promote" sizes of individual `internal_mmap` requests to at least page size bytes, consistent with the expectations of calls to `mmap`. Reviewers: cryptoad, mboerger Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52361 llvm-svn: 342745
* [fuzzer] Replace FuzzerExtFunctionsDlsymWin.cpp with ↵Jonathan Metzman2018-09-202-63/+1
| | | | | | | | | | | | | | | | | | | | | FuzzerExtFunctionsWeakAlias.cpp Summary: Replace FuzzerExtFunctionsDlsymWin.cpp with FuzzerExtFunctionsWeakAlias.cpp to get externally defined functions (eg: LLVMFuzzerInitialize, LLVMFuzzerCustomMutator, etc) working again. Also enable tests that depended on these functions (on windows) Reviewers: rnk, morehouse Reviewed By: rnk, morehouse Subscribers: rnk, morehouse, mgorny Differential Revision: https://reviews.llvm.org/D51700 llvm-svn: 342698
* [Hwasan] interceptor macro / extra comma removalDavid Carlier2018-09-201-5/+5
| | | | | | | | | | | | gcc being pedantic, removing the unnecessary comma. Reviewers: eugenis, kcc Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D52305 llvm-svn: 342680
* [winasan] Unpoison the stack in NtTerminateThreadDavid Major2018-09-201-1/+11
| | | | | | | | In long-running builds we've seen some ASan complaints during thread creation that we suspect are due to leftover poisoning from previous threads whose stacks occupied that memory. This patch adds a hook that unpoisons the stack just before the NtTerminateThread syscall. Differential Revision: https://reviews.llvm.org/D52091 llvm-svn: 342652
* [sanitizer] Make __sanitizer::CheckFailed not publicKostya Kortchinsky2018-09-201-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As far as I can tell, there is no reason why `__sanitizer::CheckFailed` should be exported. Looking back in time, it was added with the FIXME with the following by @timurrrr: ``` [*San/RTL] Fix minor breakage Grumbling: this hasn't been caught by running 'make check-{a,l,t}san check-sanitizer' ``` I can't find any detail about the breakage, all tests seem to work for me, so maybe Windows (@rnk?) or something I have no setup for. The reason to make it private (past the FIXME) is that Scudo defines its own (without callback) and I am trying to make the .so be loadable with the UBsan one (that has its own public `CheckFailed`) with as little drama as possible. Reviewers: eugenis, rnk Reviewed By: eugenis, rnk Subscribers: kubamracek, delcypher, #sanitizers, timurrrr, rnk, llvm-commits Differential Revision: https://reviews.llvm.org/D52279 llvm-svn: 342651
* [winasan] Reduce hotpatch prefix check to 8 bytesDavid Major2018-09-201-4/+4
| | | | | | | | Same idea as r310419: The 8 byte nop is a suffix of the 9 byte nop, and we need at most 6 bytes. Differential Revision: https://reviews.llvm.org/D51788 llvm-svn: 342649
* [XRay][compiler-rt] FDRLogWriter AbstractionDean Michael Berris2018-09-206-88/+289
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change introduces an `FDRLogWriter` type which is responsible for serialising metadata and function records to character buffers. This is the first step in a refactoring of the implementation of the FDR runtime to allow for more granular testing of the individual components of the implementation. The main contribution of this change is a means of hiding the details of how specific records are written to a buffer, and for managing the extents of these buffers. We make use of C++ features (templates and some metaprogramming) to reduce repetition in the act of writing out specific kinds of records to the buffer. In this process, we make a number of changes across both LLVM and compiler-rt to allow us to use the `Trace` abstraction defined in the LLVM project in the testing of the runtime implementation. This gives us a closer end-to-end test which version-locks the runtime implementation with the loading implementation in LLVM. We also allow using gmock in compiler-rt unit tests, by adding the requisite definitions in the `AddCompilerRT.cmake` module. We also add the terminfo library detection along with inclusion of the appropriate compiler flags for header include lookup. Finally, we've gone ahead and updated the FDR logging implementation to use the FDRLogWriter for the lowest-level record-writing details. Following patches will isolate the state machine transitions which manage the set-up and tear-down of the buffers we're using in multiple threads. Reviewers: mboerger, eizan Subscribers: mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D52220 llvm-svn: 342617
* [builtins] Add __emutls_unregister_key functionYi Kong2018-09-201-0/+13
| | | | | | | | | | | | This is called by Bionic on dlclose to delete the emutls pthread key. The return value of pthread_key_delete is unchecked and behaviour of multiple calls to the method is dependent on the implementation of pthread_key_delete. Differential Revision: https://reviews.llvm.org/D52251 llvm-svn: 342608
* Revert "[XRay][compiler-rt] FDRLogWriter Abstraction" and 1 more.Evgeniy Stepanov2018-09-196-284/+87
| | | | | | | | Revert the following 2 commits to fix standalone compiler-rt build: * r342523 [XRay] Detect terminfo library * r342518 [XRay][compiler-rt] FDRLogWriter Abstraction llvm-svn: 342596
* [sanitizer][fuchsia] Fix VMAR leakKostya Kortchinsky2018-09-191-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Destroy and close a range's vmar if all its memory was unmapped. This addresses some performance regression due to the proliferation of vmars when Secondary backed allocations are concerned with Scudo on Fuchsia. When a Secondary backed allocation was freed, the associated `ReservedAddressRange` was going away after unmapping the entirety of the mapping, but without getting rid of the associated vmar properly (which was created specifically for that mapping). This resulted in an increase of defunct vmars, that in turn slowed down further new vmar allocations. This appears to solve ZX-2560/ZX-2642, at least on QEMU. Reviewers: flowerhack, mcgrathr, phosek, mseaborn Reviewed By: mcgrathr Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D52242 llvm-svn: 342584
* [compiler-rt][TSan] Add TSan runtime support for Go on linux-aarch64.Arnaud A. de Grandmaison2018-09-194-2/+72
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds TSan runtime support for Go on linux-aarch64 platforms. This enables people working on golang to implement their platform/language part of the TSan support. Basic testing is done with lib/tsan/go/buildgo.sh. Additional testing will be done as part of the work done in the Go project. It is intended to support other VMA sizes, except 39 which does not have enough bits to support the Go heap requirements. Patch by Fangming Fang <Fangming.Fang@arm.com>. Reviewers: kubamracek, dvyukov, javed.absar Subscribers: mcrosier, dberris, mgorny, kristof.beyls, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D52167 llvm-svn: 342541
* [XRay] Detect terminfo libraryDean Michael Berris2018-09-191-1/+6
| | | | | | | | | Instead of assuming `-ltinfo` works, check whether there's terminfo support on the host where LLVMSupport is compiled. Follow-up to D52220. llvm-svn: 342523
* [XRay][compiler-rt] FDRLogWriter AbstractionDean Michael Berris2018-09-186-87/+279
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change introduces an `FDRLogWriter` type which is responsible for serialising metadata and function records to character buffers. This is the first step in a refactoring of the implementation of the FDR runtime to allow for more granular testing of the individual components of the implementation. The main contribution of this change is a means of hiding the details of how specific records are written to a buffer, and for managing the extents of these buffers. We make use of C++ features (templates and some metaprogramming) to reduce repetition in the act of writing out specific kinds of records to the buffer. In this process, we make a number of changes across both LLVM and compiler-rt to allow us to use the `Trace` abstraction defined in the LLVM project in the testing of the runtime implementation. This gives us a closer end-to-end test which version-locks the runtime implementation with the loading implementation in LLVM. We also allow using gmock in compiler-rt unit tests, by adding the requisite definitions in the `AddCompilerRT.cmake` module. Finally, we've gone ahead and updated the FDR logging implementation to use the FDRLogWriter for the lowest-level record-writing details. Following patches will isolate the state machine transitions which manage the set-up and tear-down of the buffers we're using in multiple threads. Reviewers: mboerger, eizan Subscribers: mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D52220 llvm-svn: 342518
* [builtins] Fix c?zdi2 on sparc64/Linux and ignore riscv32Kristina Brooks2018-09-182-4/+14
| | | | | | | | | | | | | On sparc64/Linux, sparc64 isn't defined; the canonical way of checking for sparc64 is sparc && arch64, which also works on the BSDs and Solaris. Since this problem does not occur on 32-bit architectures, riscv32 can be ignored. This fixes and refines rL324593. Patch by jrtc27 (James Clarke) Differential Revision: https://reviews.llvm.org/D43146 llvm-svn: 342504
* [libFuzzer] Avoid fuzzer symbols being hidden.Matt Morehouse2018-09-171-1/+1
| | | | | | | | Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1490845#c5. Patch By: Mike Hommey llvm-svn: 342423
* [sanitizer_common] Fuchsia now supports .preinit_arrayPetr Hosek2018-09-171-2/+2
| | | | | | | | | Support for .preinit_array has been implemented in Fuchsia's libc, add Fuchsia to the list of platforms that support this feature. Differential Revision: https://reviews.llvm.org/D52155 llvm-svn: 342357
* [XRay] Simplify FDR buffer managementDean Michael Berris2018-09-174-102/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change makes XRay FDR mode use a single backing store for the buffer queue, and have indexes into that backing store instead. We also remove the reliance on the internal allocator implementation in the FDR mode logging implementation. In the process of making this change we found an inconsistency with the way we're returning buffers to the queue, and how we're setting the extents. We take the chance to simplify the way we're managing the extents of each buffer. It turns out we do not need the indirection for the extents, so we co-host the atomic 64-bit int with the buffer object. It also seems that we've not been returning the buffers for the thread running the flush functionality when writing out the files, so we can run into a situation where we could be missing data. We consolidate all the allocation routines now into xray_allocator.h, where we used to have routines defined in xray_buffer_queue.cc. Reviewers: mboerger, eizan Subscribers: jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D52077 llvm-svn: 342356
* [XRay] Fix FDR initializationDean Michael Berris2018-09-171-3/+14
| | | | | | Follow-up to D51606. llvm-svn: 342355
* [XRay] Remove the deprecated __xray_log_init APIPetr Hosek2018-09-155-323/+72
| | | | | | | | | This API has been deprecated three months ago and shouldn't be used anymore, all clients should migrate to the new string based API. Differential Revision: https://reviews.llvm.org/D51606 llvm-svn: 342318
* [hwasan] use a single Printf per line when printing a report (more friendly ↵Kostya Serebryany2018-09-131-5/+8
| | | | | | to android logging) llvm-svn: 342164
* [XRay] Bug fixes for FDR custom event and arg-loggingDean Michael Berris2018-09-131-18/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change has a number of fixes for FDR mode in compiler-rt along with changes to the tooling handling the traces in llvm. In the runtime, we do the following: - Advance the "last record" pointer appropriately when writing the custom event data in the log. - Add XRAY_NEVER_INSTRUMENT in the rewinding routine. - When collecting the argument of functions appropriately marked, we should not attempt to rewind them (and reset the counts of functions that can be re-wound). In the tooling, we do the following: - Remove the state logic in BlockIndexer and instead rely on the presence/absence of records to indicate blocks. - Move the verifier into a loop associated with each block. Reviewers: mboerger, eizan Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D51965 llvm-svn: 342122
* [TSan] Update test valuesVlad Tsyrklevich2018-09-121-4/+4
| | | | | | | | Similarly to before, D51985 again reduced the number of registers required for the read/write routines causing this test to fail on sanitizer-x86_64-linux-autoconf. llvm-svn: 342092
* [hwasan] On every use-after-free print a developer note: the index of this ↵Kostya Serebryany2018-09-121-5/+12
| | | | | | heap object in the thread's deallocation ring buffer. Mostly useful to hwasan developers, will hopefully let us know the good size of the deallocation ring buffer llvm-svn: 342014
* [libFuzzer] [Windows] Include windows.h and psapi.h with lowercaseMartin Storsjo2018-09-112-3/+3
| | | | | | | | | | | | | This fixes building on a case sensitive filesystem with mingw-w64 headers, where all headers are lowercase, and matches how these headers are included elsewhere in compiler-rt. Also include these headers with angle brackets, as they are system headers. Differential Revision: https://reviews.llvm.org/D51913 llvm-svn: 341983
* [ASan] [Windows] Remove const from _msize function declaration parameterMartin Storsjo2018-09-111-1/+1
| | | | | | | | | This function isn't declared with a const parameter anywhere; neither in MSVC (neither in ucrt or in older msvcrt versions) nor in mingw-w64. Differential Revision: https://reviews.llvm.org/D51876 llvm-svn: 341903
* [Windows] Include BaseTsd.h with lowercaseMartin Storsjo2018-09-101-1/+1
| | | | | | | | | | This fixes building on a case sensitive filesystem with mingw-w64 headers, where all headers are lowercase. This header actually also is named with a lowercase name in the Windows SDK as well. Differential Revision: https://reviews.llvm.org/D51877 llvm-svn: 341857
* Switch to using a reserved identifier for this internal compiler-rt function.Richard Smith2018-09-082-7/+7
| | | | llvm-svn: 341736
* [hwasan] Export memory stats through /proc/$PID/maps.Evgeniy Stepanov2018-09-084-7/+46
| | | | | | | Adds a line to /proc/$PID/maps with more or less up-to-date memory stats of the process. llvm-svn: 341735
* [XRay] XRAY_NEVER_INSTRUMENT more functions, consolidate allocatorsDean Michael Berris2018-09-075-101/+144
| | | | | | | | | | | | | | | | | | | | | | Summary: In this change we apply `XRAY_NEVER_INSTRUMENT` to more functions in the profiling implementation to ensure that these never get instrumented if the compiler used to build the library is capable of doing XRay instrumentation. We also consolidate all the allocators into a single header (xray_allocator.h) which sidestep the use of the internal allocator implementation in sanitizer_common. This addresses more cases mentioned in llvm.org/PR38577. Reviewers: mboerger, eizan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51776 llvm-svn: 341647
OpenPOWER on IntegriCloud