summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/xray
Commit message (Collapse)AuthorAgeFilesLines
...
* [CMake] Remove unnecesary list of source files for Xray unit tests.Dan Liew2018-07-122-40/+39
| | | | | | | | | | | The list duplicates information already available in the parent directory so use that instead. It is unclear to me why we need to spell out the dependencies explicitly but fixing that should be done in a separate patch. Differential Revision: https://reviews.llvm.org/D49177 llvm-svn: 336905
* [XRay] basic mode PID and TID always fetchDean Michael Berris2018-07-111-6/+6
| | | | | | | | | | | | | | Summary: XRayRecords now includes a PID field. Basic handlers fetch pid and tid each time they are called instead of caching the value. Added a testcase that calls fork and checks if the child TID is different from the parent TID to verify that the processes' TID are different in the trace. Reviewers: dberris, Maknee Reviewed By: dberris, Maknee Subscribers: kpw, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D49025 llvm-svn: 336769
* Try to fix broken build due to r336663.Dan Liew2018-07-101-9/+9
| | | | | | | | | | It turns out that the `${XRAY_HEADERS}` CMake variable was already in use and was used for public headers. It seems that `lib/xray/tests/CMakeLists.txt` was depending on this. To fix rename the new `${XRAY_HEADERS}` to `${XRAY_IMPL_HEADERS}`. llvm-svn: 336699
* [CMake] Add compiler-rt header files to the list of sources for targetsDan Liew2018-07-101-4/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | when building with an IDE so that header files show up in the UI. This massively improves the development workflow in IDEs. To implement this a new function `compiler_rt_process_sources(...)` has been added that adds header files to the list of sources when the generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no changes are made to the list of source files. The function can be passed a list of headers via the `ADDITIONAL_HEADERS` argument. For each runtime library a list of explicit header files has been added and passed via `ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of headers was already present but it was stale and has been updated to reflect the current state of the source tree. The original version of this patch used file globbing (`*.{h,inc,def}`) to find the headers but the approach was changed due to this being a CMake anti-pattern (if the list of headers changes CMake won't automatically re-generate if globbing is used). The LLVM repo contains a similar function named `llvm_process_sources()` but we don't use it here for several reasons: * It depends on the `LLVM_ENABLE_OPTION` cache variable which is not set in standalone compiler-rt builds. * We would have to `include(LLVMProcessSources)` which I'd like to avoid because it would include a bunch of stuff we don't need. Differential Revision: https://reviews.llvm.org/D48422 llvm-svn: 336663
* [XRay][compiler-rt] Fixup build breakageDean Michael Berris2018-07-102-3/+1
| | | | | | | | | | | | | | Changes: - Remove static assertion on size of a structure, fails on systems where pointers aren't 8 bytes. - Use size_t instead of deducing type of arguments to `nearest_boundary`. Follow-up to D48653. llvm-svn: 336648
* [XRay][compiler-rt] xray::Array Freelist and Iterator UpdatesDean Michael Berris2018-07-109-150/+301
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We found a bug while working on a benchmark for the profiling mode which manifests as a segmentation fault in the profiling handler's implementation. This change adds unit tests which replicate the issues in isolation. We've tracked this down as a bug in the implementation of the Freelist in the `xray::Array` type. This happens when we trim the array by a number of elements, where we've been incorrectly assigning pointers for the links in the freelist of chunk nodes. We've taken the chance to add more debug-only assertions to the code path and allow us to verify these assumptions in debug builds. In the process, we also took the opportunity to use iterators to implement both `front()` and `back()` which exposes a bug in the iterator decrement operation. In particular, when we decrement past a chunk size boundary, we end up moving too far back and reaching the `SentinelChunk` prematurely. This change unblocks us to allow for contributing the non-crashing version of the benchmarks in the test-suite as well. Reviewers: kpw Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D48653 llvm-svn: 336644
* [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] Fix error message. NFCFangrui Song2018-06-191-2/+2
| | | | | | | | | | Reviewers: dberris Subscribers: delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D48313 llvm-svn: 335055
* [sanitizer] Use const char* in internal_simple_strtollVitaly Buka2018-06-172-2/+2
| | | | llvm-svn: 334900
* [XRay] Set an explicit dependency on libc++ when neededPetr Hosek2018-06-131-8/+20
| | | | | | | | | | | When XRay is being built as part of the just built compiler together with libc++ as part of the runtimes build, we need an explicit dependency from XRay to libc++ to make sure that the library is available by the time we start building XRay. Differential Revision: https://reviews.llvm.org/D48113 llvm-svn: 334575
* [XRay][profiler] Part 5: Profiler File WritingDean Michael Berris2018-06-122-6/+53
| | | | | | | | | | | | | | | | | | | | | | | Summary: This is part of the larger XRay Profiling Mode effort. This patch implements the profile writing mechanism, to allow profiles collected through the profiler mode to be persisted to files. Follow-on patches would allow us to load these profiles and start converting/analysing them through the `llvm-xray` tool. Depends on D44620. Reviewers: echristo, kpw, pelikan Reviewed By: kpw Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45998 llvm-svn: 334472
* [XRay][profiler] Part 4: Profiler Mode WiringDean Michael Berris2018-06-1210-52/+345
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is part of the larger XRay Profiling Mode effort. This patch implements the wiring required to enable us to actually select the `xray-profiling` mode, and install the handlers to start measuring the time and frequency of the function calls in call stacks. The current way to get the profile information is by working with the XRay API to `__xray_process_buffers(...)`. In subsequent changes we'll implement profile saving to files, similar to how the FDR and basic modes operate, as well as means for converting this format into those that can be loaded/visualised as flame graphs. We will also be extending the accounting tool in LLVM to support stack-based function call accounting. We also continue with the implementation to support building small histograms of latencies for the `FunctionCallTrie::Node` type, to allow us to actually approximate the distribution of latencies per function. Depends on D45758 and D46998. Reviewers: eizan, kpw, pelikan Reviewed By: kpw Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D44620 llvm-svn: 334469
* [Xray] logging forgotten headerDavid Carlier2018-06-081-0/+1
| | | | | | | | | | | | pthread.h missing for pthread_key* functions. Reviewers: dberris Reviewed By: dberris Differential Revison: https://reviews.llvm.org/D47933 llvm-svn: 334272
* [XRay][compiler-rt] Cleanup some internal XRay utilitiesDean Michael Berris2018-06-082-7/+7
| | | | | | | This change uses 'const' for the retryingWriteAll(...) API and removes unnecessary 'static' local variables in getting the temporary filename. llvm-svn: 334267
* [XRay][compiler-rt] Remove reliance on C++ ABI featuresDean Michael Berris2018-06-082-115/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes http://llvm.org/PR32274. This change adds a test to ensure that we're able to link XRay modes and the runtime to binaries that don't need to depend on the C++ standard library or a C++ ABI library. In particular, we ensure that this will work with C programs compiled+linked with XRay. To make the test pass, we need to change a few things in the XRay runtime implementations to remove the reliance on C++ ABI features. In particular, we change the thread-safe function-local-static initialisation to use pthread_* instead of the C++ features that ensure non-trivial thread-local/function-local-static initialisation. Depends on D47696. Reviewers: dblaikie, jfb, kpw, eizan Reviewed By: kpw Subscribers: echristo, eizan, kpw, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46998 llvm-svn: 334262
* [XRay][compiler-rt] Refactor recursion guard for Basic and FDR ModeDean Michael Berris2018-06-064-36/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change extracts the recursion guard implementation from FDR Mode and updates it to do the following: - Do the atomic operation correctly to be signal-handler safe. - Make it usable in both FDR and Basic Modes. Before this change, the recursion guard relied on an unsynchronised read and write on a volatile thread-local. A signal handler could then run in between the read and the write, and then be able to run instrumented code as part of the signal handling. Using an atomic exchange instead fixes that by doing a proper mutual exclusion even in the presence of signal handling. Reviewers: kpw, eizan, jfb Reviewed By: eizan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47696 llvm-svn: 334064
* [XRay][compiler-rt] Use DCHECK instead of assert(...) (NFC)Dean Michael Berris2018-06-051-10/+8
| | | | | | Use DCHECK instead of assert(...) in the XRay runtime. llvm-svn: 334002
* [XRay][compiler-rt] Use static instead of inline (NFC)Dean Michael Berris2018-06-051-13/+12
| | | | | | | | | | We don't actually need to support multiple definitions of the functions in FDR mode, but rather want to make sure that the implementation-detail functions are marked as 'static' instead. This allows the inliner to do its magic better for these functions too, since inline functions must have a unique address across translation units. llvm-svn: 334001
* [XRay][compiler-rt] Remove __xray:: in some places (NFC)Dean Michael Berris2018-06-052-12/+12
| | | | | | | This is a cosmetic change to remove unnecessary full-qualifications of types/functions that are already in the __xray:: namespace. llvm-svn: 334000
* [XRay][compiler-rt] Remove namespace __xray_fdr_internal (NFC)Dean Michael Berris2018-06-051-46/+5
| | | | | | We no longer need the __xray_fdr_internal namespace. llvm-svn: 333998
* [XRay][compiler-rt] Merge XRay FDR mode into a single file (NFC)Dean Michael Berris2018-06-053-740/+737
| | | | | | | | | | | | | We planned to have FDR mode's internals unit-tested but it turns out that we can just use end-to-end testing to verify the implementation. We're going to move towards that approach more and more going forward, so we're merging the implementation details of FDR mode into a single .cc file. We also avoid globbing in the XRay test helper macro, and instead list down the files from the lib directory. llvm-svn: 333986
* [XRay][compiler-rt] Remove __sanitizer:: from namespace __xray (NFC)Dean Michael Berris2018-06-0511-189/+163
| | | | | | | 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] Remove reliance on C++ ABI from BufferQueueDean Michael Berris2018-06-052-6/+31
| | | | | | | | | | | | | | | | | Summary: This is part of the work to address http://llvm.org/PR32274. We remove the calls to array-placement-new and array-delete. This allows us to rely on the internal memory management provided by sanitizer_common/sanitizer_internal_allocator.h. Reviewers: eizan, kpw Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47695 llvm-svn: 333982
* [XRay][compiler-rt] Remove RTTI requirement from XRay BuildsDean Michael Berris2018-06-041-0/+4
| | | | | | | | | XRay doesn't use RTTI and doesn't need it. We disable it explicitly in the CMake config, similar to how the other sanitizers already do it. Part of the work to address http://llvm.org/PR32274. llvm-svn: 333867
* Fix GCC 4.8.5 build by avoiding braced default member initializerReid Kleckner2018-05-311-1/+8
| | | | | | Use internal_memset instead. Should revive all Linux Chromium ToT bots. llvm-svn: 333678
* Missing includeStephan Bergmann2018-05-311-0/+1
| | | | | | | (For some reason, my Mac build complained about unknown pthread_once_t and PTHREAD_ONCE_INIT, but not about pthread_once itself.) llvm-svn: 333638
* [XRay] Fixup: Remove unnecessary type aliasDean Michael Berris2018-05-311-6/+4
| | | | | | Follow-up to D45758. llvm-svn: 333628
* [XRay] Fixup: Explicitly call std::make_tuple(...)Dean Michael Berris2018-05-311-2/+2
| | | | | | Follow-up to D45758. llvm-svn: 333627
* [XRay] Fixup: Address some warnings breaking buildDean Michael Berris2018-05-312-7/+7
| | | | | | Follow-up to D45758. llvm-svn: 333625
* [XRay][profiler] Part 3: Profile Collector ServiceDean Michael Berris2018-05-316-0/+556
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is part of the larger XRay Profiling Mode effort. This patch implements a centralised collector for `FunctionCallTrie` instances, associated per thread. It maintains a global set of trie instances which can be retrieved through the XRay API for processing in-memory buffers (when registered). Future changes will include the wiring to implement the actual profiling mode implementation. This central service provides the following functionality: * Posting a `FunctionCallTrie` associated with a thread, to the central list of tries. * Serializing all the posted `FunctionCallTrie` instances into in-memory buffers. * Resetting the global state of the serialized buffers and tries. Depends on D45757. Reviewers: echristo, pelikan, kpw Reviewed By: kpw Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D45758 llvm-svn: 333624
* [XRay][profiler] Part 2: XRay Function Call TrieDean Michael Berris2018-05-158-0/+837
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is part of the larger XRay Profiling Mode effort. This patch implements a central data structure for capturing statistics about XRay instrumented function call stacks. The `FunctionCallTrie` type does the following things: * It keeps track of a shadow function call stack of XRay instrumented functions as they are entered (function enter event) and as they are exited (function exit event). * When a function is entered, the shadow stack contains information about the entry TSC, and updates the trie (or prefix tree) representing the current function call stack. If we haven't encountered this function call before, this creates a unique node for the function in this position on the stack. We update the list of callees of the parent function as well to reflect this newly found path. * When a function is exited, we compute statistics (TSC deltas, function call count frequency) for the associated function(s) up the stack as we unwind to find the matching entry event. This builds upon the XRay `Allocator` and `Array` types in Part 1 of this series of patches. Depends on D45756. Reviewers: echristo, pelikan, kpw Reviewed By: kpw Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D45757 llvm-svn: 332313
* [XRay][compiler-rt] Relocate a DCHECK to the correct location.Dean Michael Berris2018-05-141-1/+2
| | | | | | | | | Fixes a bad DCHECK where the condition being checked is still valid (for iterators pointing to sentinels). Follow-up to D45756. llvm-svn: 332212
* [XRay][compiler-rt] Fixup: Use proper string comparison for DCHECKDean Michael Berris2018-05-141-1/+1
| | | | | | | | Fixes the sanitizer build. Follow-up to D46574. llvm-svn: 332211
* [XRay][compiler-rt] Fixup: Avoid C++11 narrowing in non-x86_64Dean Michael Berris2018-05-141-3/+4
| | | | | | | | This should fix non-x86_64 builds where size_t != atomic_uint64_t::Type. Follow-up to D46574. llvm-svn: 332209
* [XRay][compiler-rt] Support in-memory processing of FDR mode logsDean Michael Berris2018-05-144-61/+222
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change allows for handling the in-memory data associated with the FDR mode implementation through the new `__xray_log_process_buffers` API. With this change, we can now allow users to process the data in-memory of the process instead of through writing files. This for example allows users to stream the data of the FDR logging implementation through network sockets, or through other mechanisms instead of saving them to local files. We introduce an FDR-specific flag, for "no_file_flush" which lets the flushing logic skip opening/writing to files. This option can be defaulted to `true` when building the compiler-rt XRay runtime through the `XRAY_FDR_OPTIONS` preprocessor macro. Reviewers: kpw, echristo, pelikan, eizan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46574 llvm-svn: 332208
* [XRay][compiler-rt] Add llvm-mca assembler annotations for XRay (NFC)Dean Michael Berris2018-05-082-0/+14
| | | | | | | | | | This change adds some assembler comments to facilitate analysis with llvm-mca. In particular, we're interested in identifying and later optimising (reducing) the cost of the key functions in the XRay implementation using both static analysis (with llvm-mca, etc.) and dynamic analysis (perf profiling, etc.) of microbenchmarks. llvm-svn: 331711
* [XRay][compiler-rt] Support string-based config for Basic mode.Dean Michael Berris2018-05-047-27/+180
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This addresses http://llvm.org/PR36790. This change allows the XRay Basic Mode implementation to use the string-based initialization routine provided through `__xray_log_init_mode(...)`. In the process, we've also deprecated some flags defined for the `XRAY_OPTIONS` environment variable. We then introduce another environment variable that can control the XRay Basic Mode implementation through `XRAY_BASIC_OPTIONS`. We also rename files from `xray_inmemory_log` to `xray_basic_logging` to be more in line with the mode implementation. Depends on D46174. Reviewers: echristo, kpw, pelikan, eizan Reviewed By: kpw Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46246 llvm-svn: 331507
* [XRay][compiler-rt] Support string-based config for FDR modeDean Michael Berris2018-05-048-49/+189
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In this chage we add support for the string-based configuration mechanism for configuring FDR mode. We deprecate most of the `xray_fdr_log_*` flags that are set with the `XRAY_OPTIONS` environment variable. Instead we make the FDR implementation take defaults from the `XRAY_FDR_OPTIONS` environment variable, and use the flags defined in `xray_fdr_flags.{h,cc,inc}` for the options we support. This change addresses http://llvm.org/PR36790. Depends on D46173. Reviewers: eizan, pelikan, kpw, echristo Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D46174 llvm-svn: 331506
* [XRay][compiler-rt+docs] Introduce __xray_log_init_mode(...).Dean Michael Berris2018-05-041-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This addresses http://llvm.org/PR36790. The change Deprecates a number of functions and types in `include/xray/xray_log_interface.h` to recommend using string-based configuration of XRay through the __xray_log_init_mode(...) function. In particular, this deprecates the following: - `__xray_set_log_impl(...)` -- users should instead use the `__xray_log_register_mode(...)` and `__xray_log_select_mode(...)` APIs. - `__xray_log_init(...)` -- users should instead use the `__xray_log_init_mode(...)` function, which also requires using the `__xray_log_register_mode(...)` and `__xray_log_select_mode(...)` functionality. - `__xray::FDRLoggingOptions` -- in following patches, we'll be migrating the FDR logging implementations (and tests) to use the string-based configuration. In later stages we'll remove the `__xray::FDRLoggingOptions` type, and ask users to migrate to using the string-based configuration mechanism instead. - `__xray::BasicLoggingOptions` -- same as `__xray::FDRLoggingOptions`, we'll be removing this type later and instead rely exclusively on the string-based configuration API. We also update the documentation to reflect the new advice and remove some of the deprecated notes. Reviewers: eizan, kpw, echristo, pelikan Reviewed By: kpw Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46173 llvm-svn: 331503
* [XRay][profiler] Part 1: XRay Allocator and Array ImplementationsDean Michael Berris2018-04-296-16/+711
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is part of the larger XRay Profiling Mode effort. Here we implement an arena allocator, for fixed sized buffers used in a segmented array implementation. This change adds the segmented array data structure, which relies on the allocator to provide and maintain the storage for the segmented array. Key features of the `Allocator` type: * It uses cache-aligned blocks, intended to host the actual data. These blocks are cache-line-size multiples of contiguous bytes. * The `Allocator` has a maximum memory budget, set at construction time. This allows us to cap the amount of data each specific `Allocator` instance is responsible for. * Upon destruction, the `Allocator` will clean up the storage it's used, handing it back to the internal allocator used in sanitizer_common. Key features of the `Array` type: * Each segmented array is always backed by an `Allocator`, which is either user-provided or uses a global allocator. * When an `Array` grows, it grows by appending a segment that's fixed-sized. The size of each segment is computed by the number of elements of type `T` that can fit into cache line multiples. * An `Array` does not return memory to the `Allocator`, but it can keep track of the current number of "live" objects it stores. * When an `Array` is destroyed, it will not return memory to the `Allocator`. Users should clean up the `Allocator` independently of the `Array`. * The `Array` type keeps a freelist of the chunks it's used before, so that trimming and growing will re-use previously allocated chunks. These basic data structures are used by the XRay Profiling Mode implementation to implement efficient and cache-aware storage for data that's typically read-and-write heavy for tracking latency information. We're relying on the cache line characteristics of the architecture to provide us good data isolation and cache friendliness, when we're performing operations like searching for elements and/or updating data hosted in these cache lines. Reviewers: echristo, pelikan, kpw Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D45756 llvm-svn: 331141
* Remove 'noexcept's that do not match between header and source file.Richard Smith2018-04-241-3/+3
| | | | | | This code is ill-formed, but under -fno-exceptions compilers generally accept it (at least, prior to C++17). This allows this code to be built by Clang in C++17 mode. llvm-svn: 330765
* [XRay][compiler-rt] Add noop patch functions for unsupported arches.Keith Wyss2018-04-175-0/+30
| | | | | | | | | | | | | | Summary: Typed event patching is implemented for x86-64, but functions must be defined for other arches. Reviewers: dberris, pelikan Subscribers: nemanjai, javed.absar, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D45749 llvm-svn: 330231
* Implement trampoline and handler for typed xray event tracing.Keith Wyss2018-04-178-11/+195
| | | | | | | | | | | | | | Summary: Compiler-rt support first before defining the __xray_typedevent() lowering in llvm. I'm looking for some early feedback before I touch much more code. Reviewers: dberris Subscribers: delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D43668 llvm-svn: 330218
* [XRay] [compiler-rt] reformat and clarify CMakeLists.txt [NFC]Martin Pelikan2018-04-131-55/+36
| | | | | | | | | | | | | | | | | | Summary: - last change (+ the Apple support change) missed a lot of indentation - shorten architecture SOURCES definitions as most fit 1 line/arch - comment in English what's where, and where the different .a come from (using only the word "runtime" in the comment isn't useful, since the CMake primitive itself says "runtime" in its name) - skip unsupported architectures quickly, to avoid extra indentation Reviewers: dberris, eizan, kpw Subscribers: mgorny, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D45568 llvm-svn: 329998
* [xray] Fix OS X bots.George Karpenkov2018-04-111-15/+15
| | | | | | OS X has "fat" executables which contain the code for all architectures. llvm-svn: 329832
* [XRay][compiler-rt] Fix osx-based buildsDean Michael Berris2018-04-111-11/+22
| | | | | | This is a follow-up to D45474. llvm-svn: 329776
* [XRay][clang+compiler-rt] Support build-time mode selectionDean Michael Berris2018-04-112-11/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements the `-fxray-modes=` flag which allows users building with XRay instrumentation to decide which modes to pre-package into the binary being linked. The default is the status quo, which will link all the available modes. For this to work we're also breaking apart the mode implementations (xray-fdr and xray-basic) from the main xray runtime. This gives more granular control of which modes are pre-packaged, and picked from clang's invocation. This fixes llvm.org/PR37066. Note that in the future, we may change the default for clang to only contain the profiling implementation under development in D44620, when that implementation is ready. Reviewers: echristo, eizan, chandlerc Reviewed By: echristo Subscribers: mgorny, mgrang, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D45474 llvm-svn: 329772
* [XRay][compiler-rt] Build XRay runtime for OpenBSDDean Michael Berris2018-04-041-2/+11
| | | | | | | | | | | | | | | | | | Summary: This is D45125; the patch enables the build of XRay on OpenBSD. We also introduce some OpenBSD specific changes to the runtime implementation, involving how we get the TSC rate through the syscall interface specific to OpenBSD. Reviewers: dberris Authored by: devnexen Subscribers: dberris, mgorny, krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D45125 llvm-svn: 329189
* [XRay][compiler-rt] Add APIs for processing logs in memoryDean Michael Berris2018-03-071-5/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change adds APIs to allow logging implementations to provide a function for iterating through in-memory buffers (if they hold in-memory buffers) and a way for users to generically deal with these buffers in-process. These APIs are: - __xray_log_set_buffer_iterator(...) and __xray_log_remove_buffer_iterator(): installs and removes an iterator function that takes an XRayBuffer and yields the next one. - __xray_log_process_buffers(...): takes a function pointer that can take a mode identifier (string) and an XRayBuffer to process this data as they see fit. The intent is to have the FDR mode implementation's buffers be available through this `__xray_log_process_buffers(...)` API, so that they can be streamed from memory instead of flushed to disk (useful for getting the data to a network, or doing in-process analysis). Basic mode logging will not support this mechanism as it's designed to write the data mostly to disk. Future implementations will may depend on this API as well, to allow for programmatically working through the XRay buffers exposed to the users in some fashion. Reviewers: eizan, kpw, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43495 llvm-svn: 326866
* [XRay][compiler-rt] Make unit tests depend on implementation filesDean Michael Berris2018-03-061-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change makes changes to XRay implementation files trigger re-builds of the unit tests. Prior to this change, the unit tests were not built and run properly if the implementation files were changed during the development process. This change forces the dependency on all files in the XRay include and lib hosted files in compiler-rt. Caveat is, that new files added to the director(ies) will need a re-run of CMake to re-generate the fileset. We think this is an OK compromise, since adding new files may necessitate editing (or adding) new unit tests. It's also less likely that we're adding new files without updating the CMake configuration to include the functionality in the XRay runtime implementation anyway. Reviewers: pelikan, kpw, nglevin Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D44080 llvm-svn: 326842
OpenPOWER on IntegriCloud