summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/xray/xray_fdr_logging.cc
Commit message (Collapse)AuthorAgeFilesLines
* compiler-rt: Rename .cc file in lib/xray to .cppNico Weber2019-08-011-757/+0
| | | | | | Like r367463, but for xray. llvm-svn: 367546
* 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] Disable alignas() for thread_local objects on NetBSDMichal Gorny2018-12-231-1/+3
| | | | | | | | | | | | | | | | Disable enforcing alignas() for structs that are used as thread_local data on NetBSD. The NetBSD ld.so implementation is buggy and does not enforce correct alignment; however, clang seems to take it for granted and generates instructions that segv on wrongly aligned objects. Therefore, disable those alignas() statements on NetBSD until we can establish a better fix. Apparently, std::aligned_storage<> does not have any real effect at the moment, so we can leave it as-is. Differential Revision: https://reviews.llvm.org/D56000 llvm-svn: 350029
* [XRay] Support for FuchsiaPetr Hosek2018-11-221-1/+0
| | | | | | | | This extends XRay to support Fuchsia. Differential Revision: https://reviews.llvm.org/D52162 llvm-svn: 347443
* [XRay] Move buffer extents back to the heapDean Michael Berris2018-11-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change addresses an issue which shows up with the synchronised race between threads writing into a buffer, and another thread reading the buffer. In a lot of cases, we cannot guarantee that threads will always see the signal to finalise their buffers in time despite the grace periods and state machine maintained through atomic variables. This change addresses it by ensuring that the same instance being updated to indicate how much of the buffer is "used" by the writing thread is the same instance being read by the thread processing the buffer to be written out to disk or handled through the iterators. To do this, we ensure that all the "extents" instances live in their own the backing store, in a different contiguous page from the buffer-specific backing store. We also take precautions to ensure that the atomic variables are cache-line-sized to prevent false-sharing from unnecessarily causing cache contention on unrelated writes/reads. It's feasible that we may in the future be able to move the storage of the extents objects into the single backing store, slightly changing the way to compute the size(s) of the buffers, but in the meantime we'll settle for the isolation afforded by having a different backing store for the extents instances. Reviewers: mboerger Subscribers: jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D54684 llvm-svn: 347280
* [XRay] Add atomic fences around non-atomic reads and writesDean Michael Berris2018-11-091-0/+7
| | | | | | | | | | | | | | | | | | Summary: We need these fences to ensure that other threads attempting to read bytes in the buffer will see thw writes committed before the extents are updated. Without these, the writes can be un-committed by the time the buffer extents counter is updated -- the fences should ensure that the records written into the log have completed by the time we observe the buffer extents from different threads. Reviewers: mboerger Subscribers: jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D54291 llvm-svn: 346474
* [XRay] Use TSC delta encoding for custom/typed eventsDean Michael Berris2018-11-071-51/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change updates the version number for FDR logs to 5, and update the trace processing to support changes in the custom event records. In the runtime, since we're already writing down the record preamble to handle CPU migrations and TSC wraparound, we can use the same TSC delta encoding in the custom event and typed event records that we use in function event records. We do the same change to typed events (which were unsupported before this change in the trace processing) which now show up in the trace. Future changes should increase our testing coverage to make custom and typed events as first class entities in the FDR mode log processing tools. This change is also a good example of how we end up supporting new record types in the FDR mode implementation. This shows the places where new record types are added and supported. Depends on D54139. Reviewers: mboerger Subscribers: hiraditya, arphaman, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D54140 llvm-svn: 346293
* [XRay] Add CPU ID in Custom Event FDR RecordsDean Michael Berris2018-11-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change cuts across compiler-rt and llvm, to increment the FDR log version number to 4, and include the CPU ID in the custom event records. This is a step towards allowing us to change the `llvm::xray::Trace` object to start representing both custom and typed events in the stream of records. Follow-on changes will allow us to change the kinds of records we're presenting in the stream of traces, to incorporate the data in custom/typed events. A follow-on change will handle the typed event case, where it may not fit within the 15-byte buffer for metadata records. This work is part of the larger effort to enable writing analysis and processing tools using a common in-memory representation of the events found in traces. The work will focus on porting existing tools in LLVM to use the common representation and informing the design of a library/framework for expressing trace event analysis as C++ programs. Reviewers: mboerger, eizan Subscribers: hiraditya, mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D53920 llvm-svn: 345798
* [XRay] Migrate FDR runtime to use refactored controllerDean Michael Berris2018-10-301-632/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change completes the refactoring of the FDR runtime to support the following: - Generational buffer management. - Centralised and well-tested controller implementation. In this change we've had to: - Greatly simplify the code in xray_fdr_logging.cc to only implement the glue code for calling into the controller. - Implement the custom and typed event logging functions in the FDRLogWriter. - Imbue the `XRAY_NEVER_INSTRUMENT` attribute onto all functions in the controller implementation. Reviewers: mboerger, eizan, jfb Subscribers: jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D53858 llvm-svn: 345568
* [XRay][compiler-rt] Generational Buffer ManagementDean Michael Berris2018-10-221-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This change updates the buffer queue implementation to support using a generation number to identify the lifetime of buffers. This first part introduces the notion of the generation number, without changing the way we handle the buffers yet. What's missing here is the cleanup of the buffers. Ideally we'll keep the two most recent generations. We need to ensure that before we do any writes to the buffers, that we check the generation number(s) first. Those changes will follow-on from this change. Depends on D52588. Reviewers: mboerger, eizan Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D52974 llvm-svn: 344881
* Revert commit r344670 as the test fails on a bot ↵Douglas Yung2018-10-191-3/+5
| | | | | | http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/2683/. llvm-svn: 344771
* [XRay][compiler-rt] Generational Buffer ManagementDean Michael Berris2018-10-171-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This change updates the buffer queue implementation to support using a generation number to identify the lifetime of buffers. This first part introduces the notion of the generation number, without changing the way we handle the buffers yet. What's missing here is the cleanup of the buffers. Ideally we'll keep the two most recent generations. We need to ensure that before we do any writes to the buffers, that we check the generation number(s) first. Those changes will follow-on from this change. Depends on D52588. Reviewers: mboerger, eizan Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D52974 llvm-svn: 344670
* [XRay] Encapsulate all FD log related logic into a classPetr Hosek2018-10-161-9/+9
| | | | | | | | | | 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
* [XRay] Guard local variables with `static` and struct with unnamed namespacesFangrui Song2018-09-281-1/+4
| | | | | | | | | | | | | | | | | Summary: This is for coding standard conformance, and for fixing an ODR violation issue: __xray::ThreadLocalData is defined twice and differently in xray_fdr_logging.cc and xray_basic_logging.cc Reviewers: dberris, mboerger, eizan Reviewed By: dberris Subscribers: delcypher, jfb, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D52639 llvm-svn: 343289
* [XRay][compiler-rt] Update use of internal_mmapDean Michael Berris2018-09-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The implementation of `internal_mmap(...)` deviates from the contract of `mmap(...)` -- i.e. error returns are actually the equivalent of `errno` results. We update how XRay uses `internal_mmap(...)` to better handle these error conditions. In the process, we change the default pointers we're using from `char*` to `uint8_t*` to prevent potential usage of the pointers in the string library functions that expect to operate on `char*`. We also take the chance to "promote" sizes of individual `internal_mmap` requests to at least page size bytes, consistent with the expectations of calls to `mmap`. Reviewers: cryptoad, mboerger Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52361 llvm-svn: 342745
* [XRay][compiler-rt] FDRLogWriter AbstractionDean Michael Berris2018-09-201-83/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-48/+83
| | | | | | | | 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][compiler-rt] FDRLogWriter AbstractionDean Michael Berris2018-09-181-83/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Simplify FDR buffer managementDean Michael Berris2018-09-171-20/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change makes XRay FDR mode use a single backing store for the buffer queue, and have indexes into that backing store instead. We also remove the reliance on the internal allocator implementation in the FDR mode logging implementation. In the process of making this change we found an inconsistency with the way we're returning buffers to the queue, and how we're setting the extents. We take the chance to simplify the way we're managing the extents of each buffer. It turns out we do not need the indirection for the extents, so we co-host the atomic 64-bit int with the buffer object. It also seems that we've not been returning the buffers for the thread running the flush functionality when writing out the files, so we can run into a situation where we could be missing data. We consolidate all the allocation routines now into xray_allocator.h, where we used to have routines defined in xray_buffer_queue.cc. Reviewers: mboerger, eizan Subscribers: jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D52077 llvm-svn: 342356
* [XRay] Fix FDR initializationDean Michael Berris2018-09-171-3/+14
| | | | | | Follow-up to D51606. llvm-svn: 342355
* [XRay] Remove the deprecated __xray_log_init APIPetr Hosek2018-09-151-72/+37
| | | | | | | | | This API has been deprecated three months ago and shouldn't be used anymore, all clients should migrate to the new string based API. Differential Revision: https://reviews.llvm.org/D51606 llvm-svn: 342318
* [XRay] Bug fixes for FDR custom event and arg-loggingDean Michael Berris2018-09-131-18/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change has a number of fixes for FDR mode in compiler-rt along with changes to the tooling handling the traces in llvm. In the runtime, we do the following: - Advance the "last record" pointer appropriately when writing the custom event data in the log. - Add XRAY_NEVER_INSTRUMENT in the rewinding routine. - When collecting the argument of functions appropriately marked, we should not attempt to rewind them (and reset the counts of functions that can be re-wound). In the tooling, we do the following: - Remove the state logic in BlockIndexer and instead rely on the presence/absence of records to indicate blocks. - Move the verifier into a loop associated with each block. Reviewers: mboerger, eizan Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D51965 llvm-svn: 342122
* [XRay][compiler-rt] FDR Mode: Add extents metadata to bufferDean Michael Berris2018-07-191-2/+30
| | | | | | | | | | | | When providing raw access to the FDR mode buffers, we used to not include the extents metadata record. This oversight means that processing the buffers in-memory will lose important information that would have been written in files. This change exposes the metadata record by serializing the data similarly to how we would do it when flushing to files. llvm-svn: 337441
* [XRay][compiler-rt] FDR Mode: Allow multiple runsDean Michael Berris2018-07-181-33/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fix a bug in FDR mode which didn't allow for re-initialising the logging in the same process. This change ensures that: - When we flush the FDR mode logging, that the state of the logging implementation is `XRAY_LOG_UNINITIALIZED`. - Fix up the thread-local initialisation to use aligned storage and `pthread_getspecific` as well as `pthread_setspecific` for the thread-specific data. - Actually use the pointer provided to the thread-exit cleanup handling, instead of assuming that the thread has thread-local data associated with it, and reaching at thread-exit time. In this change we also have an explicit test for two consecutive sessions for FDR mode tracing, and ensuring both sessions succeed. Reviewers: kpw, eizan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49359 llvm-svn: 337341
* [XRay][compiler-rt] Add PID field to llvm-xray tool and add PID metadata ↵Dean Michael Berris2018-07-131-5/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | record entry in FDR mode Summary: llvm-xray changes: - account-mode - process-id {...} shows after thread-id - convert-mode - process {...} shows after thread - parses FDR and basic mode pid entries - Checks version number for FDR log parsing. Basic logging changes: - Update header version from 2 -> 3 FDR logging changes: - Update header version from 2 -> 3 - in writeBufferPreamble, there is an additional PID Metadata record (after thread id record and tsc record) Test cases changes: - fdr-mode.cc, fdr-single-thread.cc, fdr-thread-order.cc modified to catch process id output in the log. Reviewers: dberris Reviewed By: dberris Subscribers: hiraditya, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D49153 llvm-svn: 336974
* [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] Remove reliance on C++ ABI featuresDean Michael Berris2018-06-081-66/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-061-29/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-051-1/+1
| | | | | | | 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-051-13/+699
| | | | | | | | | | | | | 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-051-52/+40
| | | | | | | 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] 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-141-36/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | 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] Support string-based config for FDR modeDean Michael Berris2018-05-041-37/+60
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement trampoline and handler for typed xray event tracing.Keith Wyss2018-04-171-0/+58
| | | | | | | | | | | | | | 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] Rename Buffer.Buffer to Buffer.DataDean Michael Berris2018-02-101-3/+3
| | | | | | | | | | | | | | | | | | Summary: some compiler (msvc) treats Buffer.Buffer as constructor and refuse to compile. NFC Authored by comicfans44. Reviewers: rnk, dberris Reviewed By: dberris Subscribers: llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D40346 llvm-svn: 324807
* [XRay][compiler-rt] Implement logging implementation registrationDean Michael Berris2017-12-051-10/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change allows for registration of multiple logging implementations through a central mechanism in XRay, mapping an implementation to a "mode". Modes are strings that are used as keys to determine which implementation to install through a single API. This mechanism allows users to choose which implementation to install either from the environment variable 'XRAY_OPTIONS' with the `xray_mode=` flag, or programmatically using the `__xray_select_mode(...)` function. Here, we introduce two API functions for the XRay logging: __xray_log_register_mode(Mode, Impl): Associates an XRayLogImpl to a string Mode. We can only have one implementation associated with a given Mode. __xray_log_select_mode(Mode): Finds the associated Impl for Mode and installs it as if by calling `__xray_set_log_impl(...)`. Along with these changes, we also deprecate the xray_naive_log and xray_fdr_log flags and encourage users to instead use the xray_mode flag. Reviewers: kpw, dblaikie, eizan, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40703 llvm-svn: 319759
* [XRay][compiler-rt][Darwin] Minimal XRay build support in DarwinDean Michael Berris2017-11-281-11/+3
| | | | | | | | | | | | | | | | | | | | | | | This change is the first in a series of changes to get the XRay runtime building on macOS. This first allows us to build the minimal parts of XRay to get us started on supporting macOS development. These include: - CMake changes to allow targeting x86_64 initially. - Allowing for building the initialisation routines without `.preinit_array` support. - Use __sanitizer::SleepForMillis() to work around the lack of clock_nanosleep on macOS. - Deprecate the xray_fdr_log_grace_period_us flag, and introduce the xray_fdr_log_grace_period_ms flag instead, to use milliseconds across platforms. Reviewers: kubamracek Subscribers: llvm-commits, krytarowski, nglevin, mgorny Differential Review: https://reviews.llvm.org/D39114 llvm-svn: 319165
* [XRay] Use optimistic logging model for FDR modeDean Michael Berris2017-11-211-45/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change, the FDR mode implementation relied on at thread-exit handling to return buffers back to the (global) buffer queue. This introduces issues with the initialisation of the thread_local objects which, even through the use of pthread_setspecific(...) may eventually call into an allocation function. Similar to previous changes in this line, we're finding that there is a huge potential for deadlocks when initialising these thread-locals when the memory allocation implementation is also xray-instrumented. In this change, we limit the call to pthread_setspecific(...) to provide a non-null value to associate to the key created with pthread_key_create(...). While this doesn't completely eliminate the potential for the deadlock(s), it does allow us to still clean up at thread exit when we need to. The change is that we don't need to do more work when starting and ending a thread's lifetime. We also have a test to make sure that we actually can safely recycle the buffers in case we end up re-using the buffer(s) available from the queue on multiple thread entry/exits. This change cuts across both LLVM and compiler-rt to allow us to update both the XRay runtime implementation as well as the library support for loading these new versions of the FDR mode logging. Version 2 of the FDR logging implementation makes the following changes: * Introduction of a new 'BufferExtents' metadata record that's outside of the buffer's contents but are written before the actual buffer. This data is associated to the Buffer handed out by the BufferQueue rather than a record that occupies bytes in the actual buffer. * Removal of the "end of buffer" records. This is in-line with the changes we described above, to allow for optimistic logging without explicit record writing at thread exit. The optimistic logging model operates under the following assumptions: * Threads writing to the buffers will potentially race with the thread attempting to flush the log. To avoid this situation from occuring, we make sure that when we've finalized the logging implementation, that threads will see this finalization state on the next write, and either choose to not write records the thread would have written or write the record(s) in two phases -- first write the record(s), then update the extents metadata. * We change the buffer queue implementation so that once it's handed out a buffer to a thread, that we assume that buffer is marked "used" to be able to capture partial writes. None of this will be safe to handle if threads are racing to write the extents records and the reader thread is attempting to flush the log. The optimism comes from the finalization routine being required to complete before we attempt to flush the log. This is a fairly significant semantics change for the FDR implementation. This is why we've decided to update the version number for FDR mode logs. The tools, however, still need to be able to support older versions of the log until we finally deprecate those earlier versions. Reviewers: dblaikie, pelikan, kpw Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D39526 llvm-svn: 318733
* [XRay] [compiler-rt] fix build by including errno.h into FDR modeMartin Pelikan2017-10-281-0/+1
| | | | | | The build got broken after D39277 (and rL316816) deleted <cerrno>. llvm-svn: 316821
* [XRay][compiler-rt] Remove more STL dependenices from FDR modeDean Michael Berris2017-10-271-25/+21
| | | | | | | | | | | | | | | | | | | | | Summary: This change removes dependencies on STL types: - std::aligned_storage -- we're using manually-aligned character buffers instead for metadata and function records. - std::tuple -- use a plain old struct instead. This is an incremental step in removing all STL references from the compiler-rt implementation of XRay (llvm.org/PR32274). Reviewers: dblaikie, pelikan, kpw Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D39277 llvm-svn: 316816
* [XRay][compiler-rt] Always place the CPU record first for every bufferDean Michael Berris2017-10-171-7/+7
| | | | | | | | | | | | | | | | | | | | | Summary: In FDR Mode, when we set up a new buffer for a thread that's just overflowed, we must place the CPU identifier with the TSC record as the first record. This is so that we can reconstruct all the function entry/exit with deltas rooted on a TSC record for the CPU at the beginning of the buffer. Without doing this, the tools are rejecting the log for cases when we've overflown and have different buffers that don't have the CPU and TSC records as the first entry in the buffers. Reviewers: pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38995 llvm-svn: 315987
* [XRay] [compiler-rt] make sure single threaded programs get traced tooMartin Pelikan2017-10-041-0/+10
| | | | | | | | | | | | | | | Summary: When the XRay user calls the API to finish writing the log, the thread which is calling the API still hasn't finished and therefore won't get its trace written. Add a test for only the main thread to check this. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38493 llvm-svn: 314875
* [XRay] [compiler-rt] FDR logging arg1 handlerMartin Pelikan2017-09-281-3/+14
| | | | | | | | | | | | | | Summary: Write out records about logged function call first arguments. D32840 implements the reading of this in llvm-xray. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32844 llvm-svn: 314378
* [XRay][compiler-rt] Use a single global volatile recursion guard for FDR ↵Dean Michael Berris2017-09-121-3/+4
| | | | | | | | | | | | | | | | | | | | handlers Summary: Before this change, the recursion guard for the flight data recorder (FDR) mode handlers were independent. This change makes it so that when a handler is already in the process of running and somehow the same or another handler starts running -- say in a signal handler, while the XRay handler is executing -- then we can use the same thread-local recursion guard to stop the second handler from running. Reviewers: kpw, eizan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D37612 llvm-svn: 312992
* [XRay][compiler-rt][NFC] Refactor global TLS variables behind an accessor ↵Dean Michael Berris2017-08-291-5/+6
| | | | | | | | | | | | | | | | | | | | | | function. Summary: This change hides all the initialization of thread_local variables used by the XRay FDR mode implementation behind a function call. This makes initialization of thread-local data to be done lazily, instead of eagerly when they're done as globals. It also gives us an isolation mechanism if/when we want to change the TLS implementation from using the C++ thread_local keyword, for something more ad-hoc (potentialy using pthread directly) on some platforms or set-ups where we cannot use the C++ thread_local variables. Reviewers: kpw, eizan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D37248 llvm-svn: 311997
OpenPOWER on IntegriCloud