summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/xray/xray_init.cc
Commit message (Collapse)AuthorAgeFilesLines
* compiler-rt: Rename .cc file in lib/xray to .cppNico Weber2019-08-011-115/+0
| | | | | | Like r367463, but for xray. llvm-svn: 367546
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [xray] Detect MPROTECT and error out when it's enabled (on NetBSD)Michal Gorny2018-12-231-0/+3
| | | | | | | | | | Add a CheckMPROTECT() routine to detect when pax MPROTECT is enabled on NetBSD, and error xray out when it is. The solution is adapted from existing CheckASLR(). Differential Revision: https://reviews.llvm.org/D56049 llvm-svn: 350030
* Prioritize the constructor call of __local_xray_dyninit()Kamil Rytarowski2018-11-061-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: For platforms without preinit support (such as NetBSD/amd64) the initialization routine __xray_init() was called in non-deterministic order compared to other constructors. This caused breakage failures as xray routines attempted to execute code with assumption of being initialized, which was no always true. Use GCC/Clang extension to set maximal priority to the constructor calling __xray_init(). This code switches away from C++ lambda form, as it did not allow to specify this compiler extension. Reviewers: dberris, joerg Reviewed By: dberris Subscribers: llvm-commits, mgorny, #sanitizers Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54136 llvm-svn: 346222
* [Xray] Darwin providing defined value for weak symbols to fix linkage issueDavid Carlier2018-09-051-0/+9
| | | | | | - Temporary hack to make the buildbot failure stop on Darwin. llvm-svn: 341445
* [asan] Fix deadlock issue on FreeBSD, caused by use of .preinit_array in ↵Fangrui Song2018-07-011-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | rL325240 Summary: Without this patch, clang -fsanitize=address -xc =(printf 'int main(){}') -o a; ./a => deadlock in __asan_init>AsanInitInternal>AsanTSDInit>...>__getcontextx_size>_rtld_bind>rlock_acquire(rtld_bind_lock, &lockstate) libexec/rtld-elf/rtld.c wlock_acquire(rtld_bind_lock, &lockstate); if (obj_main->crt_no_init) preinit_main(); // unresolved PLT functions cannot be called here lib/libthr/thread/thr_rtld.c uc_len = __getcontextx_size(); // unresolved PLT function in libthr.so.3 check-xray tests currently rely on .preinit_array so we special case in xray_init.cc Subscribers: srhines, kubamracek, krytarowski, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D48806 llvm-svn: 336067
* [XRay][compiler-rt] Remove __sanitizer:: from namespace __xray (NFC)Dean Michael Berris2018-06-051-14/+10
| | | | | | | This is a non-functional change that removes the full qualification of functions in __sanitizer:: being used in __xray. llvm-svn: 333983
* [XRay][compiler-rt][Darwin] Use dynamic initialisation as an alternativeDean Michael Berris2017-11-291-1/+8
| | | | | | | | | | | | | | | | Summary: In cases where we can't use the .preinit_array section (as in Darwin for example) we instead use dynamic initialisation. We know that this alternative approach will race with the initializers of other objects at global scope, but this is strictly better than nothing. Reviewers: kubamracek, nglevin Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40599 llvm-svn: 319366
* [XRay][compiler-rt][Darwin] Minimal XRay build support in DarwinDean Michael Berris2017-11-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | This change is the first in a series of changes to get the XRay runtime building on macOS. This first allows us to build the minimal parts of XRay to get us started on supporting macOS development. These include: - CMake changes to allow targeting x86_64 initially. - Allowing for building the initialisation routines without `.preinit_array` support. - Use __sanitizer::SleepForMillis() to work around the lack of clock_nanosleep on macOS. - Deprecate the xray_fdr_log_grace_period_us flag, and introduce the xray_fdr_log_grace_period_ms flag instead, to use milliseconds across platforms. Reviewers: kubamracek Subscribers: llvm-commits, krytarowski, nglevin, mgorny Differential Review: https://reviews.llvm.org/D39114 llvm-svn: 319165
* Revert "[XRay][darwin] Initial XRay in Darwin Support"Dean Michael Berris2017-11-101-2/+1
| | | | | | This reverts r317875. llvm-svn: 317877
* [XRay][darwin] Initial XRay in Darwin SupportDean Michael Berris2017-11-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: This change implements the changes required in both clang and compiler-rt to allow building XRay-instrumented binaries in Darwin. For now we limit this to x86_64. We also start building the XRay runtime library in compiler-rt for osx. A caveat to this is that we don't have the tests set up and running yet, which we'll do in a set of follow-on changes. This patch uses the monorepo layout for the coordinated change across multiple projects. Reviewers: kubamracek Subscribers: mgorny, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D39114 llvm-svn: 317875
* [XRay][compiler-rt] Allow for building the XRay runtime without PREINIT ↵Dean Michael Berris2017-08-031-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 309909
* [XRay][compiler-rt] Do not print the warning when the binary is not XRay ↵Dean Michael Berris2017-07-311-1/+2
| | | | | | | | | | | | | | | | | instrumented. Summary: Currently when the XRay runtime is linked into a binary that doesn't have the instrumentation map, we print a warning unconditionally. This change attempts to make this behaviour more quiet. Reviewers: kpw, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D35789 llvm-svn: 309534
* [XRay][compiler-rt] Support patching/unpatching specific functionsDean Michael Berris2017-05-041-0/+4
| | | | | | | | | | | | | | | | | | 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 llvm-svn: 302112
* [XRay][compiler-rt] Use sanitizer_common's atomic opsDean Michael Berris2017-03-271-13/+10
| | | | | | | | | | | Instead of std::atomic APIs for atomic operations, we instead use APIs include with sanitizer_common. This allows us to, at runtime, not have to depend on potentially dynamically provided implementations of these atomic operations. Fixes http://llvm.org/PR32274. llvm-svn: 298833
* [XRay][compiler-rt][NFC] Turn ProudCase functions to humbleCase functionsDean Michael Berris2017-02-071-1/+1
| | | | | | | | | | | | | | | Summary: As pointed out in casual reading of the XRay codebase, that we had some interesting named functions that didn't quite follow the LLVM coding conventions. Reviewers: chandlerc, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29625 llvm-svn: 294373
* [XRay][compiler-rt] Disable XRay instrumentation of the XRay runtime.Dean Michael Berris2016-11-161-1/+2
| | | | | | | | | | | | | | | | | | | | | Summary: Adds a CMake check for whether the compiler used to build the XRay library supports XRay-instrumentation. If the compiler we're using does support the `-fxray-instrument` flag (i.e. recently-built Clang), we define the XRAY_NEVER_INSTRUMENT macro that then makes sure that the XRay runtime functions never get XRay-instrumented. This prevents potential weirdness involved with building the XRay library with a Clang that supports XRay-instrumentation, and is attempting to XRay-instrument the build of compiler-rt. Reviewers: majnemer, rSerge, echristo Subscribers: mehdi_amini, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D26597 llvm-svn: 287068
* [compiler-rt] Do not introduce __sanitizer namespace globallyAnna Zaks2016-09-151-0/+1
| | | | | | | | | | | | The definitions in sanitizer_common may conflict with definitions from system headers because: The runtime includes the system headers after the project headers (as per LLVM coding guidelines). lib/sanitizer_common/sanitizer_internal_defs.h pollutes the namespace of everything defined after it, which is all/most of the sanitizer .h and .cc files and the included system headers with: using namespace __sanitizer; // NOLINT This patch solves the problem by introducing the namespace only within the sanitizer namespaces as proposed by Dmitry. Differential Revision: https://reviews.llvm.org/D21947 llvm-svn: 281657
* [compiler-rt][XRay] Address follow-up comments to initial interface and ↵Dean Michael Berris2016-07-291-5/+7
| | | | | | | | | | | | | | | | | | initialisation code This addresses some comments from D21612, which contains the following changes: - Update __xray_patch() and __xray_unpatch() API documentation to not imply asynchrony. - Introduce a scope cleanup mechanism to make sure we can roll-back changes to the XRayPatching global atomic. - Introduce a few more comments for potential extension points for other platforms (for the implementation details of patching and un-patching). Reviewers: eugenis, rnk, kcc, echristo, majnemer Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D22911 llvm-svn: 277124
* [compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due ↵Dean Michael Berris2016-07-211-0/+66
| | | | | | | | | | | | | | | | | | | | | | | to extraneous and missing dependencies and attempts to build on unsupported OSes Summary: This is a fixed-up version of D21612, to address failure identified post-commit. Original commit description: This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting). Fixes include: - Gating XRay build to only Linux x86_64 and with the right dependencies in case it is the only library being built - Including <cstddef> to fix std::size_t issue Reviewers: kcc, rnk, echristo Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D22611 llvm-svn: 276251
* Revert r276117 "[XRay] Basic initialization and flag definition for XRay ↵Hans Wennborg2016-07-201-68/+0
| | | | | | | | | | | | | | | | | | | | | | | runtime" and also the follow-up "[xray] Only build xray on Linux for now" Two build errors were reported on the llvm-commits list: [ 88%] Building CXX object lib/xray/CMakeFiles/clang_rt.xray-x86_64.dir/xray_flags.cc.o /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/lib/xray/xray_init.cc:23:10: fatal error: 'llvm/Support/ELF.h' file not found #include "llvm/Support/ELF.h" ^ and In file included from /w/src/llvm.org/projects/compiler-rt/lib/xray/xray_interface.cc:16: /w/src/llvm.org/projects/compiler-rt/lib/xray/xray_interface_internal.h:36:8: error: no type named 'size_t' in namespace 'std' std::size_t Entries; ~~~~~^ llvm-svn: 276186
* [compiler-rt] [XRay] Basic initialization and flag definition for XRay runtimeDean Michael Berris2016-07-201-0/+68
Summary: This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting). Depends on D19904 Reviewers: echristo, kcc, rnk Subscribers: rnk, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D21612 llvm-svn: 276117
OpenPOWER on IntegriCloud