summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/xray/xray_fdr_logging.cc
Commit message (Collapse)AuthorAgeFilesLines
...
* [XRay][compiler-rt] Remove use of std::mutex and std::shared_ptr from global ↵Dean Michael Berris2017-08-021-7/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 309792
* [XRay][compiler-rt] Runtime changes to support custom event loggingDean Michael Berris2017-05-121-43/+107
| | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 302857
* [XRay][compiler-rt] Use emulated TSC when CPU supports rdtscp, but cannot ↵Douglas Yung2017-04-181-3/+10
| | | | | | | | | | | | | | | | | | | | | determine the CPU frequency A problem arises if a machine supports the rdtscp instruction, but the processor frequency cannot be determined by the function getTSCFrequency(). In this case, we want to use the emulated TSC instead. This patch implements that by adding a call to getTSCFrequency() from probeRequiredCPUFeatures(), and the function only returns true if both the processor supports rdtscp and the CPU frequency can be determined. This should fix PR32620. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32067 llvm-svn: 300525
* Fix compile errorIsmail Donmez2017-04-121-0/+1
| | | | llvm-svn: 300041
* [XRay][compiler-rt] Add another work-around to XRay FDR tests when TSC ↵Douglas Yung2017-04-121-1/+2
| | | | | | | | | | | | | | | | | emulation is needed This patch applies a work-around to the XRay FDR tests when TSC emulation is needed because the processor frequency cannot be determined. This fixes PR32620 using the suggestion given by Dean in comment 1. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31967 llvm-svn: 300017
* [XRay][compiler-rt] Add support for TSC emulation for x86_64 to ↵Douglas Yung2017-04-111-1/+15
| | | | | | | | | | | | | | | | xray_fdr_logging.cc Previously in r297800, a work-around was created to use TSC emulation on x86_64 when RDTSCP was not available on the host. A similar change was needed in the file xray_fdr_logging.cc which this patch ports over to that file. Eventually the code should be refactored as there will be 3 locations with the same code, but that can be done as a separate step. This patch is just to keep the test from failing on my machine due to an illegal instruction since RDTSCP is not available on my x86_64 linux VM. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31909 llvm-svn: 299922
* [XRay] [compiler-rt] Write buffer length to FDR log before writing buffer.Dean Michael Berris2017-03-291-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 298982
* [XRay][compiler-rt] Add an end-to-end test for FDR LoggingDean Michael Berris2017-03-291-10/+9
| | | | | | | | | | | | | | | | | | 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 llvm-svn: 298977
* [XRay][compiler-rt] Use sanitizer_common's atomic opsDean Michael Berris2017-03-271-36/+44
| | | | | | | | | | | 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] Refactor logic for xray fdr logging. NFC.Dean Michael Berris2017-03-151-342/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Separated the IO and the thread local storage state machine of logging from the writing of log records once the contents are deterministic. Finer granularity functions are provided as inline functions in the same header such that stack does not grow due to the functions being separated. An executable utility xray_fdr_log_printer is also implemented to use the finest granularity functions to produce binary test data in the FDR format with a relatively convenient text input. For example, one can take a file with textual contents layed out in rows and feed it to the binary to generate data that llvm-xray convert can then read. This is a convenient way to build a test suite for llvm-xray convert to ensure it's robust to the fdr format. Example: $cat myFile.txt NewBuffer : { time = 2 , Tid=5} NewCPU : { CPU =1 , TSC = 123} Function : { FuncId = 5, TSCDelta = 3, EntryType = Entry } Function : { FuncId = 5, TSCDelta = 5, EntryType = Exit} TSCWrap : { TSC = 678 } Function : { FuncId = 6, TSCDelta = 0, EntryType = Entry } Function : { FuncId = 6, TSCDelta = 50, EntryType = Exit } EOB : { } $cat myFile.txt | ./bin/xray_fdr_log_printer > /tmp/binarydata.bin $./bin/llvm-xray convert -output-format=yaml -output=- /tmp/binarydata.bin yaml format comes out as expected. Reviewers: dberris, pelikan Reviewed By: dberris Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D30850 llvm-svn: 297801
* [XRay] [compiler-rt] Allow logging the first argument of a function call.Dean Michael Berris2017-03-061-0/+1
| | | | | | | | | | | | | | | | | | | 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 llvm-svn: 297000
* [XRay] [compiler-rt] [NFC] Annotate unused variables for the compiler.Dean Michael Berris2017-02-281-1/+1
| | | | | | | | | | | | | | | | | Summary: Use a common definition of a "this variable is unused" annotation for useless variables only present for their lambda global initializers, to silence gcc's warning. Reviewers: dberris Reviewed By: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29860 llvm-svn: 296449
* [Xray] fix building the runtime with GCC.Benjamin Kramer2017-02-231-14/+16
| | | | | | | GCC has a warning about enum bitfields that cannot be disabled. Do the ugly thing and go through uint8_t for all the values. llvm-svn: 295967
* Re-submit r294826 "Fix -Wsign-compare" reverted in r294842 by mistake.Vitaly Buka2017-02-111-3/+1
| | | | | | Fix -Wsign-compare - this might not be quite right, but preserves behavior llvm-svn: 294868
* This reverts commits r294826 and r294781 as they break linking on powerpc.Vitaly Buka2017-02-111-1/+3
| | | | | | | | | | Revert "Fix -Wsign-compare - this might not be quite right, but preserves behavior" Revert "[XRay] Implement powerpc64le xray." This reverts commit r294826. This reverts commit r294781. llvm-svn: 294842
* Fix -Wsign-compare - this might not be quite right, but preserves behaviorDavid Blaikie2017-02-111-3/+1
| | | | llvm-svn: 294826
* [XRay] Refactor TSC related functions into a single header. NFC.Tim Shen2017-02-101-10/+3
| | | | | | | | | | | | | Summary: The implementation, however, is in different arch-specific files, unless it's emulated. Reviewers: dberris, pelikan, javed.absar Subscribers: aemerson, llvm-commits Differential Revision: https://reviews.llvm.org/D29796 llvm-svn: 294777
* [XRAY] [compiler-rt] [NFC] Fixing the bit twiddling of Function Id in FDR ↵Dean Michael Berris2017-02-091-1/+1
| | | | | | | | | | | | | | | | | | | logging mode. Summary: Fixing a bug I found when testing a reader for the FDR format. Function ID is now correctly packed into the 28 bits which are documented for it instead of being masked to all ones. Reviewers: dberris, pelikan, eugenis Reviewed By: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29698 llvm-svn: 294563
* [XRay][compiler-rt][NFC] Turn ProudCase functions to humbleCase functionsDean Michael Berris2017-02-071-9/+9
| | | | | | | | | | | | | | | 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] Use gettid instead of getpid in FDR mode.Dean Michael Berris2017-02-061-2/+3
| | | | | | | | | | | | | | Summary: This was pointed out that FDR mode didn't quite put the thread ID in the buffers, but instead would write down the parent process ID. Reviewers: pelikan, rSerge Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29484 llvm-svn: 294166
* [XRay][ARM32][AArch64] Fix unstable FDR tests on weak-ordering CPUsSerge Rogatch2017-01-301-4/+4
| | | | | | | | | | | | | | Summary: Change from `compare_exchange_weak()` to `compare_exchange_strong()` where appropriate, because on ARM ( http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/3190 , http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/3191 ) and AArch64 ( http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/3900 ) it fails even in single-threaded scenarios. Reviewers: dberris, rengolin Reviewed By: rengolin Subscribers: aemerson, llvm-commits, iid_iunknown Differential Revision: https://reviews.llvm.org/D29286 llvm-svn: 293505
* [XRay][compiler-rt] XRay Flight Data Recorder ModeDean Michael Berris2017-01-251-0/+542
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-528/+0
| | | | | | This reverts rL290852 as it breaks aarch64 and arm. llvm-svn: 290854
* [XRay][compiler-rt] XRay Flight Data Recorder ModeDean Michael Berris2017-01-031-0/+528
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
OpenPOWER on IntegriCloud