summaryrefslogtreecommitdiff
path: root/include
Commit message (Collapse)AuthorAgeFilesLines
...
* [scudo] s/unsigned long/size_t/ for __scudo_set_rss_limitKostya Kortchinsky2018-01-041-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: `__scudo_set_rss_limit`'s `LimitMb` should really be a `size_t`. Update accordingly the prototype. To avoid the `NOLINT` and conform with the other Sanitizers, use the sanitizers types for the internal definition. This should have no functional change. Additionally, capitalize a variable name to follow the LLVM coding standards. Reviewers: alekseyshl, flowerhack Reviewed By: alekseyshl Subscribers: #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D41704 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@321803 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Make function declarations C-compatiblePetr Hosek2017-12-219-37/+37
| | | | | | | | | | | | | | | | | The public sanitizer headers are intended to be usable from either C++ or C, but they declare no-argument functions with the syntax that is not a proper prototype declaration in C. This goes unnoticed until someone uses -Wsystem-headers. Patch By: mcgrathr Reviewers: phosek, vitalybuka Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D41475 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@321305 91177308-0d34-0410-b5e6-96231b3b80d8
* Added a separate install target for compilert-rt-headersIlya Biryukov2017-12-151-1/+19
| | | | | | | | | | | | | | | | | | | Summary: This patch adds a new install target `install-compilert-rt-headers`, that is similar to `install-clang-headers`. It allows to install the headers without installing all of compiler-rt. Reviewers: alekseyshl, beanz Reviewed By: beanz Subscribers: smeenai, beanz, mgorny, #sanitizers, kcc, llvm-commits Differential Revision: https://reviews.llvm.org/D41244 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@320808 91177308-0d34-0410-b5e6-96231b3b80d8
* [scudo] Adding a public Scudo interfaceKostya Kortchinsky2017-12-132-0/+35
| | | | | | | | | | | | | | | | Summary: The first and only function to start with allows to set the soft or hard RSS limit at runtime. Add associated tests. Reviewers: alekseyshl Reviewed By: alekseyshl Subscribers: mgorny, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D41128 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@320611 91177308-0d34-0410-b5e6-96231b3b80d8
* Hardware-assisted AddressSanitizer (compiler-rt)Evgeniy Stepanov2017-12-092-0/+34
| | | | | | | | | | | | | | Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@320231 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt] Implement logging implementation registrationDean Michael Berris2017-12-051-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change allows for registration of multiple logging implementations through a central mechanism in XRay, mapping an implementation to a "mode". Modes are strings that are used as keys to determine which implementation to install through a single API. This mechanism allows users to choose which implementation to install either from the environment variable 'XRAY_OPTIONS' with the `xray_mode=` flag, or programmatically using the `__xray_select_mode(...)` function. Here, we introduce two API functions for the XRay logging: __xray_log_register_mode(Mode, Impl): Associates an XRayLogImpl to a string Mode. We can only have one implementation associated with a given Mode. __xray_log_select_mode(Mode): Finds the associated Impl for Mode and installs it as if by calling `__xray_set_log_impl(...)`. Along with these changes, we also deprecate the xray_naive_log and xray_fdr_log flags and encourage users to instead use the xray_mode flag. Reviewers: kpw, dblaikie, eizan, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40703 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319759 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt] Migrate basic mode logging to the XRay frameworkDean Michael Berris2017-11-211-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, XRay's basic (naive mode) logging would be initialised and installed in an adhoc manner. This patch ports the implementation of the basic (naive mode) logging implementation to use the common XRay framework. We also make the following changes to reduce the variance between the usage model of basic mode from FDR (flight data recorder) mode: - Allow programmatic control of the size of the buffers dedicated to per-thread records. This removes some hard-coded constants and turns them into runtime-controllable flags and through an Options structure. - Default the `xray_naive_log` option to false. For now, the only way to start basic mode is to set the environment variable, or set the default at build-time compiler options. Because of this change we've had to update a couple of tests relying on basic mode being always on. - Removed the reliance on a non-trivially destructible per-thread resource manager. We use a similar trick done in D39526 to use pthread_key_create() and pthread_setspecific() to ensure that the per-thread cleanup handling is performed at thread-exit time. We also radically simplify the code structure for basic mode, to move most of the implementation in the `__xray` namespace. Reviewers: pelikan, eizan, kpw Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40164 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@318734 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sanitizers] New sanitizer API to purge allocator quarantine.Alex Shlyapnikov2017-10-231-0/+7
| | | | | | | | | | | | | | | | Summary: Purging allocator quarantine and returning memory to OS might be desired between fuzzer iterations since, most likely, the quarantine is not going to catch bugs in the code under fuzz, but reducing RSS might significantly prolong the fuzzing session. Reviewers: cryptoad Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D39153 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@316347 91177308-0d34-0410-b5e6-96231b3b80d8
* [tsan] Add Mutex annotation flag for constant-initialized ↵Dmitry Vyukov2017-10-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | __tsan_mutex_linker_init behavior Add a new flag, _⁠_tsan_mutex_not_static, which has the opposite sense of _⁠_tsan_mutex_linker_init. When the new _⁠_tsan_mutex_not_static flag is passed to _⁠_tsan_mutex_destroy, tsan ignores the destruction unless the mutex was also created with the _⁠_tsan_mutex_not_static flag. This is useful for constructors that otherwise woud set _⁠_tsan_mutex_linker_init but cannot, because they are declared constexpr. Google has a custom mutex with two constructors, a "linker initialized" constructor that relies on zero-initialization and sets ⁠_⁠_tsan_mutex_linker_init, and a normal one which sets no tsan flags. The "linker initialized" constructor is morally constexpr, but we can't declare it constexpr because of the need to call into tsan as a side effect. With this new flag, the normal c'tor can set _⁠_tsan_mutex_not_static, the "linker initialized" constructor can rely on tsan's lazy initialization, and _⁠_tsan_mutex_destroy can still handle both cases correctly. Author: Greg Falcon (gfalcon) Reviewed in: https://reviews.llvm.org/D39095 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@316209 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt] Write out arg1 payload in naive mode loggingDean Michael Berris2017-10-051-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This change allows the XRay basic (naive) mode logging implementation to start writing the payload entries through the arg1 logging handler. This implementation writes out the records that the llvm-xray tool and the trace reader library will start processing in D38550. This introduces a new payload record type which logs the data through the in-memory buffer. It uses the same size/alignment that the normal XRay record entries use. We use a new record type to indicate these new entries, so that the trace reader library in LLVM can start reading these entries. Depends on D38550. Reviewers: pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38551 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314968 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay] [compiler-rt] FDR logging arg1 handlerMartin Pelikan2017-09-281-0/+3
| | | | | | | | | | | | | | Summary: Write out records about logged function call first arguments. D32840 implements the reading of this in llvm-xray. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32844 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314378 91177308-0d34-0410-b5e6-96231b3b80d8
* [lsan] Add __lsan_default_optionsVitaly Buka2017-09-221-0/+4
| | | | | | For consistency with asan, msan, tsan and ubsan. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314048 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt] Handle tail-call exits in the XRay runtimeDean Michael Berris2017-09-181-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This change starts differentiating tail exits from normal exits. We also increase the version number of the "naive" log to version 2, which will be the starting version where these records start appearing. In FDR mode we treat the tail exits as normal exits, and are thus subject to the same treatment with regard to record unwriting. Updating the version number is important to signal older builds of the llvm-xray tool that do not deal with the tail exit records must fail early (and that users should only use the llvm-xray tool built after the support for tail exits to get accurate handling of these records). Depends on D37964. Reviewers: kpw, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D37965 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313515 91177308-0d34-0410-b5e6-96231b3b80d8
* [ASAN] Revert r313303 - Add macro denoting availability of new ↵Eric Fiselier2017-09-141-4/+0
| | | | | | | | | | | `__asan_handle_no_return()` function. It was pointed out that compiler-rt has always defined the symbol, but only recently added it to the public headers. Meaning that libc++abi can re-declare it instead of needing this macro. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313306 91177308-0d34-0410-b5e6-96231b3b80d8
* [ASAN] Add macro denoting availability of new `__asan_handle_no_return()` ↵Eric Fiselier2017-09-141-0/+4
| | | | | | | | | | | | | | | | | | | function. Summary: Libc++abi attempts to use the newly added `__asan_handle_no_return()` when built under ASAN. Unfortunately older versions of compiler-rt do not provide this symbol, and so libc++abi needs a way to detect if `asan_interface.h` actually provides the function. This patch adds the macro `SANITIZER_ASAN_INTERFACE_HAS_HANDLE_NO_RETURN` which can be used to detect the availability of the new function. Reviewers: phosek, kcc, vitalybuka, alekseyshl Reviewed By: phosek Subscribers: mclow.lists, cfe-commits Differential Revision: https://reviews.llvm.org/D37871 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313303 91177308-0d34-0410-b5e6-96231b3b80d8
* Prevent DCE on __lsan_is_turned_off and re-enable test caseFrancis Ricci2017-09-081-0/+2
| | | | | | | | | | | | | | | Summary: -dead_strip in ld64 strips weak interface symbols, which I believe is most likely the cause of this test failure. Re-enable after marking the interface function as used. Reviewers: alekseyshl, kubamracek, kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D37635 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@312824 91177308-0d34-0410-b5e6-96231b3b80d8
* [asan] Move __asan_handle_no_return to public headerPetr Hosek2017-08-281-0/+4
| | | | | | | | | | | | | | Heretofore asan_handle_no_return was used only by interceptors, i.e. code private to the ASan runtime. However, on systems without interceptors, code like libc++abi is built with -fsanitize=address itself and should call asan_handle_no_return directly from __cxa_throw so that no interceptor is required. Patch by Roland McGrath Differential Revision: https://reviews.llvm.org/D36811 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@311869 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt] Allow for building the XRay runtime without PREINIT ↵Dean Michael Berris2017-08-031-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initialization. Summary: Define a build-time configuration option for the XRay runtime to determine whether the archive will add an entry to the `.preinit_array` section of the binary. We also allow for initializing the XRay data structures with an explicit call to __xray_init(). This allows us to give users the capability to initialize the XRay data structures on demand. This can allow us to start porting XRay to platforms where `.preinit_array` isn't a supported section. It also allows us to limit the effects of XRay in the initialization sequence for applications that are sensitive to this kind of interference (i.e. large binaries) or those that want to package XRay control in libraries. Future changes should allow us to build two different library archives for the XRay runtime, and allow clang users to determine which version to link. Reviewers: dblaikie, kpw, pelikan Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D36080 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@309909 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt] Remove use of std::mutex and std::shared_ptr from global ↵Dean Michael Berris2017-08-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | scope. Summary: This change attempts to remove all the dependencies we have on std::mutex and any std::shared_ptr construction in global variables. We instead use raw pointers to these objects, and construct them on the heap. In cases where it's possible, we lazily initialize these pointers. While we do not have a replacement for std::shared_ptr yet in compiler-rt, we use this work-around to avoid having to statically initialize the objects as globals. Subsequent changes should allow us to completely remove our dependency on std::shared_ptr and instead have our own implementation of the std::shared_ptr and std::weak_ptr semantics (or completely rewrite the implementaton to not need these standard-library provided abstractions). Reviewers: dblaikie, kpw, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36078 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@309792 91177308-0d34-0410-b5e6-96231b3b80d8
* [sancov] Implement __sanitizer_cov_reset.Evgeniy Stepanov2017-07-271-2/+5
| | | | | | | | | | | | Summary: Clears all collected coverage. Reviewers: kcc Subscribers: srhines, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D35958 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@309333 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt][NFC] Add a name for argument to __xray_set_handler_arg1(...)Dean Michael Berris2017-06-191-1/+2
| | | | | | | Just makes the interface consistent with the other functions in include/xray/xray_interface.h. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@305658 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer-coverage] nuke more stale codeKostya Serebryany2017-06-021-2/+0
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@304504 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer-coverage] nuke more stale codeKostya Serebryany2017-06-011-4/+0
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@304500 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer-coverage] remove stale code (old coverage); compiler-rt part Kostya Serebryany2017-05-311-3/+0
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@304318 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt] Add __xray_remove_customevent_handler(...)Dean Michael Berris2017-05-221-0/+4
| | | | | | | This change adds __xray_remove_customevent_handler(...) to be consistent with other APIs that add/remove handlers. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@303526 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay] Fix build with libc++ (NFC).Eugene Zelenko2017-05-121-4/+5
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302962 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt] Runtime changes to support custom event loggingDean Michael Berris2017-05-121-0/+4
| | | | | | | | | | | | | | | | | | | | Summary: This change implements support for the custom event logging sleds and intrinsics at runtime. For now it only supports handling the sleds in x86_64, with the implementations for other architectures stubbed out to do nothing. NOTE: Work in progress, uploaded for exposition/exploration purposes. Depends on D27503, D30018, and D33032. Reviewers: echristo, javed.absar, timshen Subscribers: mehdi_amini, nemanjai, llvm-commits Differential Revision: https://reviews.llvm.org/D30630 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302857 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt] Add function id utilities for XRayDean Michael Berris2017-05-051-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This change allows us to provide users and implementers of XRay handlers a means of converting XRay function id's to addresses. This, in combination with the facilities provided in D32695, allows users to find out: - How many function id's there are defined in the current binary. - Get the address of the function associated with this function id. - Patch only specific functions according to their requirements. While we don't directly provide symbolization support in XRay, having the function's address lets users determine this information easily either during runtime, or offline with tools like 'addr2line'. Reviewers: dblaikie, echristo, pelikan Subscribers: kpw, llvm-commits Differential Revision: https://reviews.llvm.org/D32846 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302210 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt][NFC] Update comments to doxygen format; group functions ↵Dean Michael Berris2017-05-041-40/+42
| | | | | | better. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302121 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt] Support patching/unpatching specific functionsDean Michael Berris2017-05-041-0/+8
| | | | | | | | | | | | | | | | | | Summary: This change allows us to patch/unpatch specific functions using the function ID. This is useful in cases where implementations might want to do coverage-style, or more fine-grained control of which functions to patch or un-patch at runtime. Depends on D32693. Reviewers: dblaikie, echristo, kpw Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32695 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302112 91177308-0d34-0410-b5e6-96231b3b80d8
* [tsan] Detect races on modifying accesses in Swift codeKuba Mracek2017-05-031-0/+1
| | | | | | | | | | 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
* tsan: support linker init flag in __tsan_mutex_destroyDmitry Vyukov2017-05-011-1/+2
| | | | | | | | | | | | | | | | 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
* [XRay][compiler-rt] Document and update the XRay Logging APIDean Michael Berris2017-05-011-0/+171
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In this patch we document the requirements for implementations that want to install handlers for the dynamically-controlled XRay "framework". This clarifies what the expectations are for implementations that want to install their handlers using this API (similar to how the FDR logging implementation does so). It also gives users some guarantees on semantics for the APIs. If all goes well, users can decide to use the XRay APIs to control the tracing/logging at the application level, without having to depend on implementation details of the installed logging implementation. This lets users choose the implementation that comes with compiler-rt, or potentially multiple other implementations that use the same APIs. We also add one convenience function (__xray_remove_log_impl()) for explicitly removing the currently installed log implementation. Reviewers: kpw, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32579 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@301784 91177308-0d34-0410-b5e6-96231b3b80d8
* [tsan] Publish the TSan external API in tsan_interface.hKuba Mracek2017-04-211-0/+15
| | | | | | | | | | | | | | | Let's make the TSan external API available and commented in the public header: void *__tsan_external_register_tag(const char *object_type); void __tsan_external_assign_tag(void *addr, void *tag); void __tsan_external_read(void *addr, void *caller_pc, void *tag); void __tsan_external_write(void *addr, void *caller_pc, void *tag); Differential Revision: https://reviews.llvm.org/D32358 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@301003 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer-coverage] remove more unused codeKostya Serebryany2017-04-191-8/+0
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@300780 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer-coverage] remove run-time support for ↵Kostya Serebryany2017-04-191-2/+0
| | | | | | -fsanitize-coverage=indirect-calls git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@300775 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer-coverage] remove run-time support for the deprecated ↵Kostya Serebryany2017-04-191-19/+0
| | | | | | -fsanitize-coverage=8bit-counters git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@300745 91177308-0d34-0410-b5e6-96231b3b80d8
* This patch causes the installation of headers for the sanitizer and/or xray ↵Catherine Moore2017-04-111-15/+19
| | | | | | | | | | | | | to be disabled when COMPILER_RT_BUILD_SANITIZERS=OFF and/or COMPILER_RT_BUILD_XRAY=OFF. Reviewer: dberris Subscribers: dberris, mgorny, llvm-commits, clm Differential Revision: https://reviews.llvm.org/D31864 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@299940 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay] [compiler-rt] Write buffer length to FDR log before writing buffer.Dean Michael Berris2017-03-291-4/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently the FDR log writer, upon flushing, dumps a sequence of buffers from its freelist to disk. A reader can read the first buffer up to an EOB record, but then it is unclear how far ahead to scan to find the next threads traces. There are a few ways to handle this problem. 1. The reader has externalized knowledge of the buffer size. 2. The size of buffers is in the file header or otherwise encoded in the log. 3. Only write out the portion of the buffer with records. When released, the buffers are marked with a size. 4. The reader looks for memory that matches a pattern and synchronizes on it. 2 and 3 seem the most flexible and 2 does not rule 3 out. This is an implementation of 2. In addition, the function handler for fdr more aggressively checks for finalization and makes an attempt to release its buffer. Reviewers: pelikan, dberris Reviewed By: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31384 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@298982 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt] Add an end-to-end test for FDR LoggingDean Michael Berris2017-03-292-1/+11
| | | | | | | | | | | | | | | | | | Summary: This change exercises the end-to-end functionality defined in the FDR logging implementation. We also prepare for being able to run traces generated by the FDR logging implementation from being analysed with the llvm-xray command that comes with the LLVM distribution. This also unblocks D31385, D31384, and D31345. Reviewers: kpw, pelikan Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D31452 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@298977 91177308-0d34-0410-b5e6-96231b3b80d8
* tsan: add new mutex annotationsDmitry Vyukov2017-03-262-0/+122
| | | | | | | | | | | | | | | | 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
* [asan] add one more argument to __sanitizer_print_memory_profile, remove a ↵Kostya Serebryany2017-03-151-1/+3
| | | | | | redundant weak definition. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@297914 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay] [compiler-rt] Allow logging the first argument of a function call.Dean Michael Berris2017-03-061-1/+18
| | | | | | | | | | | | | | | | | | | Summary: Functions with the LOG_ARGS_ENTRY sled kind at their beginning will be handled in a way to (optionally) pass their first call argument to your logging handler. For practical and performance reasons, only the first argument is supported, and only up to 64 bits. Reviewers: javed.absar, dberris Reviewed By: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29703 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@297000 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt] XRay Flight Data Recorder ModeDean Michael Berris2017-01-252-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In this change we introduce the notion of a "flight data recorder" mode for XRay logging, where XRay logs in-memory first, and write out data on-demand as required (as opposed to the naive implementation that keeps logging while tracing is "on"). This depends on D26232 where we implement the core data structure for holding the buffers that threads will be using to write out records of operation. This implementation only currently works on x86_64 and depends heavily on the TSC math to write out smaller records to the inmemory buffers. Also, this implementation defines two different kinds of records with different sizes (compared to the current naive implementation): a MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord entries are meant to write out information like the thread ID for which the metadata record is defined for, whether the execution of a thread moved to a different CPU, etc. while a FunctionRecord represents the different kinds of function call entry/exit records we might encounter in the course of a thread's execution along with a delta from the last time the logging handler was called. While this implementation is not exactly what is described in the original XRay whitepaper, this one gives us an initial implementation that we can iterate and build upon. Reviewers: echristo, rSerge, majnemer Subscribers: mehdi_amini, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D27038 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@293015 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[XRay][compiler-rt] XRay Flight Data Recorder Mode"Dean Michael Berris2017-01-032-57/+0
| | | | | | This reverts rL290852 as it breaks aarch64 and arm. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@290854 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay][compiler-rt] XRay Flight Data Recorder ModeDean Michael Berris2017-01-032-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In this change we introduce the notion of a "flight data recorder" mode for XRay logging, where XRay logs in-memory first, and write out data on-demand as required (as opposed to the naive implementation that keeps logging while tracing is "on"). This depends on D26232 where we implement the core data structure for holding the buffers that threads will be using to write out records of operation. This implementation only currently works on x86_64 and depends heavily on the TSC math to write out smaller records to the inmemory buffers. Also, this implementation defines two different kinds of records with different sizes (compared to the current naive implementation): a MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord entries are meant to write out information like the thread ID for which the metadata record is defined for, whether the execution of a thread moved to a different CPU, etc. while a FunctionRecord represents the different kinds of function call entry/exit records we might encounter in the course of a thread's execution along with a delta from the last time the logging handler was called. While this implementation is not exactly what is described in the original XRay whitepaper, this one gives us an initial implementation that we can iterate and build upon. Reviewers: echristo, rSerge, majnemer Subscribers: mehdi_amini, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D27038 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@290852 91177308-0d34-0410-b5e6-96231b3b80d8
* [sancov] __sanitizer_dump_coverage apiMike Aizatsky2016-12-121-0/+5
| | | | | | | | Subscribers: kubabrecka, mgorny Differential Revision: https://reviews.llvm.org/D26758 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@289498 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizers] __sanitizer_get_module_and_offset_for_pc interface functionMike Aizatsky2016-12-051-0/+7
| | | | | | | | | | | | Summary: The function computes full module name and coverts pc into offset. Reviewers: kcc Subscribers: kubabrecka Differential Revision: https://reviews.llvm.org/D26820 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@288711 91177308-0d34-0410-b5e6-96231b3b80d8
* [XRay] Support AArch64 in compiler-rtDean Michael Berris2016-11-211-0/+7
| | | | | | | | | | | | | | | | | | This patch adds XRay support in compiler-rt for AArch64 targets. This patch is one of a series: LLVM: https://reviews.llvm.org/D26412 Clang: https://reviews.llvm.org/D26415 Author: rSerge Reviewers: rengolin, dberris Subscribers: aemerson, mgorny, llvm-commits, iid_iunknown Differential Revision: https://reviews.llvm.org/D26413 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@287517 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt][XRay] Support tail call sledsDean Michael Berris2016-10-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change depends on D23986 which adds tail call-specific sleds. For now we treat them first as normal exits, and in the future leave room for implementing this as a different kind of log entry. The reason for deferring the change is so that we can keep the naive logging implementation more accurate without additional complexity for reading the log. The accuracy is gained in effectively interpreting call stacks like: A() B() C() Which when tail-call merged will end up not having any exit entries for A() nor B(), but effectively in turn can be reasoned about as: A() B() C() Although we lose the fact that A() had called B() then had called C() with the naive approach, a later iteration that adds the explicit tail call entries would be a change in the log format and thus necessitate a version change for the header. We can do this later to have a chance at releasing some tools (in D21987) that are able to handle the naive log format, then support higher version numbers of the log format too. Reviewers: echristo, kcc, rSerge, majnemer Subscribers: mehdi_amini, llvm-commits, dberris Differential Revision: https://reviews.llvm.org/D23988 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@284178 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status