summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/xray/xray_utils.cc
Commit message (Collapse)AuthorAgeFilesLines
* [XRay][compiler-rt] Reduce XRay log spamDean Michael Berris2017-12-131-1/+2
| | | | | | | | | | | | This change makes XRay print the log file output only when the verbosity level is higher than 0. It reduces the log spam in the default case when we want XRay running silently, except when there are actual fatal/serious errors. We also update the documentation to show how to get the information after the change to the default behaviour. llvm-svn: 320550
* [XRay][compiler-rt] Add an end-to-end test for FDR LoggingDean Michael Berris2017-03-291-4/+1
| | | | | | | | | | | | | | | | | | 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
* Fix a build break with xrayDean Michael Berris2017-03-141-0/+1
| | | | | | | | | | | | Summary: Building compiler-rt with clang 3.7 broken, could not find mkstemp Reviewers: dberris, bkramer Reviewed By: dberris Differential Revision: https://reviews.llvm.org/D30389 llvm-svn: 297794
* [XRay] Refactor TSC related functions into a single header. NFC.Tim Shen2017-02-101-39/+0
| | | | | | | | | | | | | 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] Turn ProudCase functions to humbleCase functionsDean Michael Berris2017-02-071-2/+2
| | | | | | | | | | | | | | | 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
* [compiler-rt] Fix xray compilation errors: errno and size_tKrzysztof Parzyszek2017-01-251-0/+1
| | | | | | | Include errno.h, and use size_t instead of std::size_t, since stddef.h was included (and not cstddef). llvm-svn: 293057
* [XRay][compiler-rt] XRay Flight Data Recorder ModeDean Michael Berris2017-01-251-0/+165
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-150/+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/+150
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