summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/xray/xray_utils.cc
Commit message (Collapse)AuthorAgeFilesLines
* compiler-rt: Rename .cc file in lib/xray to .cppNico Weber2019-08-011-195/+0
| | | | | | Like r367463, but for xray. llvm-svn: 367546
* [compiler-rt] Set the ZX_VMO_RESIZABLE option for zx_vmo_createPetr Hosek2019-05-021-1/+1
| | | | | | | | | | | | | Currently VMO in Zircon create using the zx_vmo_create is resizable by default, but we'll be changing this in the future, requiring an explicit flag to make the VMO resizable. Prepare for this change by passing ZX_VMO_RESIZABLE option to all zx_vmo_create calls that need resizable VMO. Differential Revision: https://reviews.llvm.org/D61450 llvm-svn: 359803
* 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] Support for FuchsiaPetr Hosek2018-11-221-2/+99
| | | | | | | | This extends XRay to support Fuchsia. Differential Revision: https://reviews.llvm.org/D52162 llvm-svn: 347443
* [XRay] Encapsulate all FD log related logic into a classPetr Hosek2018-10-161-46/+20
| | | | | | | | | | This abstracts away the file descriptor related logic which makes it easier to port XRay to platform that don't use file descriptors or file system for writing the log data, such as Fuchsia. Differential Revision: https://reviews.llvm.org/D52161 llvm-svn: 344578
* Remove a path-length limitation for the xray logfile.Douglas Yung2018-10-011-3/+2
| | | | | | | | | | | | Reviewers: MaskRay Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52728 Patch by Jeremy Morse! llvm-svn: 343524
* [sanitizer] Use const char* in internal_simple_strtollVitaly Buka2018-06-171-1/+1
| | | | llvm-svn: 334900
* [XRay][compiler-rt] Cleanup some internal XRay utilitiesDean Michael Berris2018-06-081-6/+6
| | | | | | | 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 __sanitizer:: from namespace __xray (NFC)Dean Michael Berris2018-06-051-1/+1
| | | | | | | 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] 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