summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/xray/tests/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* [compiler-rt][tests] Propagate COMPILER_RT_UNITTEST_LINK_FLAGSHubert Tong2019-05-011-1/+4
| | | | | | | | | | | | | | | | | | | | `COMPILER_RT_UNITTEST_LINK_FLAGS` is dropped in many places, unlike `COMPILER_RT_UNITTEST_CFLAGS`. This patch attempts to remove that inconsistency. Previously reviewed as part of D58951. Reviewers: sfertile, peter.smith, pzheng, phosek, Hahnfeld, nemanjai, jasonliu Reviewed By: sfertile Subscribers: jsji, kubamracek, dberris, mgorny, delcypher, jdoerfert, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D60143 llvm-svn: 359733
* [compiler-rt] Cleanup usage of C++ ABI libraryJonas Hahnfeld2019-02-161-3/+4
| | | | | | | | | | | | | Add missed value "libcxxabi" and introduce SANITIZER_TEST_CXX for linking unit tests. This needs to be a full C++ library and cannot be libcxxabi. Recommit r354132 which I reverted in r354153 because it broke a sanitizer bot. This was because of the "fixes" for pthread linking, so I've removed these changes. Differential Revision: https://reviews.llvm.org/D58012 llvm-svn: 354198
* Revert "[compiler-rt] Cleanup usage of C++ ABI library"Jonas Hahnfeld2019-02-151-4/+3
| | | | | | | This reverts r354132 because it breaks sanitizer-x86_64-linux: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/19915 llvm-svn: 354153
* [compiler-rt] Cleanup usage of C++ ABI libraryJonas Hahnfeld2019-02-151-3/+4
| | | | | | | | | Add missed value "libcxxabi" and introduce SANITIZER_TEST_CXX for linking unit tests. This needs to be a full C++ library and cannot be libcxxabi. Differential Revision: https://reviews.llvm.org/D58012 llvm-svn: 354132
* [xray][tests][RHDTS] Add -lstdc++ after LLVM libs, resolving link error with ↵Hubert Tong2019-02-131-2/+3
| | | | | | | | | | | | | | | | | | | | | RHDTS Summary: A link error was encountered when using the Red Hat Developer Toolset. In the RHDTS, `libstdc++.so` is a linker script that may resolve symbols to a static library. This patch places `-lstdc++` later in the ordering. Reviewers: sfertile, nemanjai, tstellar, dberris Reviewed By: dberris Subscribers: dberris, mgorny, delcypher, jdoerfert, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D58144 llvm-svn: 353905
* Fix XRayTest link on FreeBSD (and likely NetBSD too)Dimitry Andric2019-01-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As reported on llvm-testers, during 8.0.0-rc1 testing I got errors while building of `XRayTest`, during `check-all`: ``` [100%] Generating XRayTest-x86_64-Test /home/dim/llvm/8.0.0/rc1/Phase3/Release/llvmCore-8.0.0-rc1.obj/./lib/libLLVMSupport.a(Signals.cpp.o): In function `llvm::sys::PrintStackTrace(llvm::raw_ostream&)': Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x24): undefined reference to `backtrace' Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x254): undefined reference to `llvm::itaniumDemangle(char const*, char*, unsigned long*, int*)' clang-8: error: linker command failed with exit code 1 (use -v to see invocation) gmake[3]: *** [projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build.make:73: projects/compiler-rt/lib/xray/tests/unit/XRayTest-x86_64-Test] Error 1 gmake[3]: Target 'projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build' not remade because of errors. gmake[2]: *** [CMakeFiles/Makefile2:33513: projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/all] Error 2 gmake[2]: Target 'CMakeFiles/check-all.dir/all' not remade because of errors. gmake[1]: *** [CMakeFiles/Makefile2:737: CMakeFiles/check-all.dir/rule] Error 2 gmake[1]: Target 'check-all' not remade because of errors. gmake: *** [Makefile:277: check-all] Error 2 [Release Phase3] check-all failed ``` This is because the `backtrace` function requires `-lexecinfo` on BSD platforms. To fix this, detect the `execinfo` library in `cmake/config-ix.cmake`, and add it to the unit test link flags. Additionally, since the code in `sys::PrintStackTrace` makes use of `itaniumDemangle`, also add `-lLLVMDemangle`. (Note that this is more of a general problem with libLLVMSupport, but I'm looking for a quick fix now so it can be merged to the 8.0 branch.) Reviewers: dberris, hans, mgorny, samsonov Reviewed By: dberris Subscribers: krytarowski, delcypher, erik.pilkington, #sanitizers, emaste, llvm-commits Differential Revision: https://reviews.llvm.org/D57181 llvm-svn: 352234
* [xray] [tests] Detect and handle missing LLVMTestingSupport gracefullyMichal Gorny2018-12-211-0/+4
| | | | | | | | | | | | | | | | | | Add a code to properly test for presence of LLVMTestingSupport library when performing a stand-alone build, and skip tests requiring it when it is not present. Since the library is not installed, llvm-config reported empty --libs for it and the tests failed to link with undefined references. Skipping the two fdr_* test files is better than failing to build, and should be good enough until we find a better solution. NB: both installing LLVMTestingSupport and building it automatically from within compiler-rt sources are non-trivial. The former due to dependency on gtest, the latter due to tight integration with LLVM source tree. Differential Revision: https://reviews.llvm.org/D55891 llvm-svn: 349899
* [XRay] Fix TSC and atomic custom/typed event accountingDean Michael Berris2018-11-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow-on change to D53858 which turns out to have had a TSC accounting bug when writing out function exit records in FDR mode. This change adds a number of tests to ensure that: - We are handling the delta between the exit TSC and the last TSC we've seen. - We are writing the custom event and typed event records as a single update to the buffer extents. - We are able to catch boundary conditions when loading FDR logs. We introduce a TSC matcher to the test helpers, which we use in the testing/verification of the TSC accounting change. Reviewers: mboerger Subscribers: mgorny, hiraditya, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D53967 llvm-svn: 345905
* [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
* [XRay] Clean up XRay build configurationDean Michael Berris2018-09-241-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [XRay][compiler-rt] FDRLogWriter AbstractionDean Michael Berris2018-09-201-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[XRay][compiler-rt] FDRLogWriter Abstraction" and 1 more.Evgeniy Stepanov2018-09-191-16/+4
| | | | | | | | 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
* [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-181-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [XRay][compiler-rt] Use `SANITIZER_CXX_ABI_LIBRARY` for XRay unit testsDean Michael Berris2018-07-161-2/+2
| | | | | | | | | | | | | | | | | | Summary: Fix a TODO in CMake config for XRay tests to use the detected C++ ABI library in the tests. Also make the tests depend on the llvm-xray target when built in-tree. Reviewers: kpw, eizan Reviewed By: eizan Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D49358 llvm-svn: 337142
* [CMake] Remove unnecesary list of source files for Xray unit tests.Dan Liew2018-07-121-40/+12
| | | | | | | | | | | 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][compiler-rt] xray::Array Freelist and Iterator UpdatesDean Michael Berris2018-07-101-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [XRay][profiler] Part 4: Profiler Mode WiringDean Michael Berris2018-06-121-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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][compiler-rt] Refactor recursion guard for Basic and FDR ModeDean Michael Berris2018-06-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Merge XRay FDR mode into a single file (NFC)Dean Michael Berris2018-06-051-5/+38
| | | | | | | | | | | | | 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][profiler] Part 2: XRay Function Call TrieDean Michael Berris2018-05-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] 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-111-4/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] 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
* Add Xray instrumentation support to FreeBSDKamil Rytarowski2018-02-151-2/+5
| | | | | | | | | | | | | | | | | | | Summary: - Enabling the build. - Using assembly for the cpuid parts. - Using thr_self FreeBSD call to get the thread id Patch by: David CARLIER Reviewers: dberris, rnk, krytarowski Reviewed By: dberris, krytarowski Subscribers: emaste, stevecheckoway, nglevin, srhines, kubamracek, dberris, mgorny, krytarowski, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D43278 llvm-svn: 325240
* Revert "[XRay][darwin] Initial XRay in Darwin Support"Dean Michael Berris2017-11-101-33/+4
| | | | | | This reverts r317875. llvm-svn: 317877
* [XRay][darwin] Initial XRay in Darwin SupportDean Michael Berris2017-11-101-4/+33
| | | | | | | | | | | | | | | | | | | | | | 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] Fix CMake for X-RAY testsGeorge Karpenkov2017-10-141-1/+2
| | | | | | | | Correctly depend on llvm-xray, make sure unit tests are being run. Differential Revision: https://reviews.llvm.org/D38917 llvm-svn: 315827
* [XRay][compiler-rt] Enable the XRay compiler-rt unit tests.Dean Michael Berris2017-08-311-6/+5
| | | | | | | | | | | | | | | | | | | Summary: Before this change we seemed to not be running the unit tests, and therefore we set out to run them. In the process of making this happen we found a divergence between the implementation and the tests. This includes changes to both the CMake files as well as the implementation and headers of the XRay runtime. We've also updated documentation on the changed functions. Reviewers: kpw, eizan Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D37290 llvm-svn: 312202
* Fix multi-architecture build for lib/xray.George Karpenkov2017-08-211-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D36881 llvm-svn: 311379
* [sanitizers CMake] NFC Refactor the logic for compiling and generating testsGeorge Karpenkov2017-08-151-23/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | into a function. Most CMake configuration under compiler-rt/lib/*/tests have almost-the-same-but-not-quite functions of the form add_X_[unit]tests for compiling and running the tests. Much of the logic is duplicated with minor variations across different sub-folders. This can harm productivity for multiple reasons: For newcomers, resulting CMake files are very large, hard to understand, and hide the intention of the code. Changes for enabling certain architectures end up being unnecessarily large, as they get duplicated across multiple folders. Adding new sub-projects requires more effort than it should, as a developer has to again copy-n-paste the configuration, and it's not even clear from which sub-project it should be copy-n-pasted. With this change the logic of compile-and-generate-a-set-of-tests is extracted into a function, which hopefully makes writing and reading CMake much easier. Differential Revision: https://reviews.llvm.org/D36116 llvm-svn: 310971
* [sanitizer tests CMake] Factor out CMake logic for compiling sanitizer testsGeorge Karpenkov2017-07-281-14/+3
| | | | | | | | | | | Currently there's a large amount of CMake logic duplication for compiling sanitizer tests. If we add more sanitizers, the duplication will get even worse. This change factors out common compilation commands into a macro available to all sanitizers. llvm-svn: 309405
* [XRay][compiler-rt] Use sanitizer_common's atomic opsDean Michael Berris2017-03-271-1/+1
| | | | | | | | | | | 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
* [Compiler-rt][XRAY][MIPS] Support xray on mips/mipsel/mips64/mips64elSagar Thakur2017-02-151-1/+1
| | | | | | | | | Summary: Adds support for xray on mips/mipsel/mips64/mips64el. Reviewed by sdardis, dberris Differential: D27699 llvm-svn: 295166
* [XRay][compiler-rt] XRay Flight Data Recorder ModeDean Michael Berris2017-01-251-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 293015
* Revert "[XRay][compiler-rt] XRay Flight Data Recorder Mode"Dean Michael Berris2017-01-031-6/+4
| | | | | | This reverts rL290852 as it breaks aarch64 and arm. llvm-svn: 290854
* [XRay][compiler-rt] XRay Flight Data Recorder ModeDean Michael Berris2017-01-031-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 290852
* [XRay][compiler-rt] Explicitly add dependency to pthreadDean Michael Berris2016-12-061-0/+1
| | | | | | | | This should fix the sanitizer bootstrap builds. Follow-up to D26232. llvm-svn: 288860
* [XRay][compiler-rt] Only add unit tests if we're building XRay.Dean Michael Berris2016-12-061-1/+1
| | | | | | | | | | As constructed before this patch, in case we run into case where we don't actually build the XRay library, we really ought to not be adding the unit test runs. This should fix the bootstrap build failures. This is a follow-up further to D26232. llvm-svn: 288788
* [XRay][compiler-rt] XRay Buffer QueueDean Michael Berris2016-12-061-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | This implements a simple buffer queue to manage a pre-allocated queue of fixed-sized buffers to hold XRay records. We need this to support Flight Data Recorder (FDR) mode. We also implement this as a sub-library first to allow for development before actually using it in an implementation. Some important properties of the buffer queue: - Thread-safe enqueueing/dequeueing of fixed-size buffers. - Pre-allocation of buffers at construction. This is a re-roll of the previous attempt to submit, because it caused failures in arm and aarch64. Reviewers: majnemer, echristo, rSerge Subscribers: tberghammer, danalbert, srhines, modocache, mehdi_amini, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D26232 llvm-svn: 288775
* Revert "[XRay][compiler-rt] XRay Buffer Queue"Dean Michael Berris2016-11-251-58/+0
| | | | | | Broke the build on arm7 and aarch64. llvm-svn: 287911
* [XRay][compiler-rt] XRay Buffer QueueDean Michael Berris2016-11-251-0/+58
Summary: This implements a simple buffer queue to manage a pre-allocated queue of fixed-sized buffers to hold XRay records. We need this to support Flight Data Recorder (FDR) mode. We also implement this as a sub-library first to allow for development before actually using it in an implementation. Some important properties of the buffer queue: - Thread-safe enqueueing/dequeueing of fixed-size buffers. - Pre-allocation of buffers at construction. Reviewers: majnemer, rSerge, echristo Subscribers: mehdi_amini, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D26232 llvm-svn: 287910
OpenPOWER on IntegriCloud