summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/xray/tests
Commit message (Collapse)AuthorAgeFilesLines
...
* [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][compiler-rt] Remove __sanitizer:: from namespace __xray (NFC)Dean Michael Berris2018-06-052-2/+2
| | | | | | | This is a non-functional change that removes the full qualification of functions in __sanitizer:: being used in __xray. llvm-svn: 333983
* [XRay] Fixup: Explicitly call std::make_tuple(...)Dean Michael Berris2018-05-311-2/+2
| | | | | | Follow-up to D45758. llvm-svn: 333627
* [XRay][profiler] Part 3: Profile Collector ServiceDean Michael Berris2018-05-312-0/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is part of the larger XRay Profiling Mode effort. This patch implements a centralised collector for `FunctionCallTrie` instances, associated per thread. It maintains a global set of trie instances which can be retrieved through the XRay API for processing in-memory buffers (when registered). Future changes will include the wiring to implement the actual profiling mode implementation. This central service provides the following functionality: * Posting a `FunctionCallTrie` associated with a thread, to the central list of tries. * Serializing all the posted `FunctionCallTrie` instances into in-memory buffers. * Resetting the global state of the serialized buffers and tries. Depends on D45757. Reviewers: echristo, pelikan, kpw Reviewed By: kpw Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D45758 llvm-svn: 333624
* [XRay][profiler] Part 2: XRay Function Call TrieDean Michael Berris2018-05-153-0/+257
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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][profiler] Part 1: XRay Allocator and Array ImplementationsDean Michael Berris2018-04-293-0/+185
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is part of the larger XRay Profiling Mode effort. Here we implement an arena allocator, for fixed sized buffers used in a segmented array implementation. This change adds the segmented array data structure, which relies on the allocator to provide and maintain the storage for the segmented array. Key features of the `Allocator` type: * It uses cache-aligned blocks, intended to host the actual data. These blocks are cache-line-size multiples of contiguous bytes. * The `Allocator` has a maximum memory budget, set at construction time. This allows us to cap the amount of data each specific `Allocator` instance is responsible for. * Upon destruction, the `Allocator` will clean up the storage it's used, handing it back to the internal allocator used in sanitizer_common. Key features of the `Array` type: * Each segmented array is always backed by an `Allocator`, which is either user-provided or uses a global allocator. * When an `Array` grows, it grows by appending a segment that's fixed-sized. The size of each segment is computed by the number of elements of type `T` that can fit into cache line multiples. * An `Array` does not return memory to the `Allocator`, but it can keep track of the current number of "live" objects it stores. * When an `Array` is destroyed, it will not return memory to the `Allocator`. Users should clean up the `Allocator` independently of the `Array`. * The `Array` type keeps a freelist of the chunks it's used before, so that trimming and growing will re-use previously allocated chunks. These basic data structures are used by the XRay Profiling Mode implementation to implement efficient and cache-aware storage for data that's typically read-and-write heavy for tracking latency information. We're relying on the cache line characteristics of the architecture to provide us good data isolation and cache friendliness, when we're performing operations like searching for elements and/or updating data hosted in these cache lines. Reviewers: echristo, pelikan, kpw Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D45756 llvm-svn: 331141
* [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-152-7/+11
| | | | | | | | | | | | | | | | | | | 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
* [XRay] Rename Buffer.Buffer to Buffer.DataDean Michael Berris2018-02-101-4/+4
| | | | | | | | | | | | | | | | | | 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] Add missing include to unit testJonas Hahnfeld2017-12-271-0/+1
| | | | | | | FDRLoggingTest::MultiThreadedCycling uses std::array so we need to include the right C++ header and not rely on transitive dependencies. llvm-svn: 321485
* [XRay] Use optimistic logging model for FDR modeDean Michael Berris2017-11-211-15/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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-313-10/+7
| | | | | | | | | | | | | | | | | | | 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] Remove the xray_fdr_log_printer_toolDean Michael Berris2017-04-112-332/+0
| | | | | | | | | | | | | | | | | | | | Summary: We can move this functionality into LLVM's tools instead, as it no longer is strictly required for the compiler-rt testing infrastructure. It also is blocking the successful bootstrapping of the clang compiler due to a missing virtual destructor in one of the flag parsing library. Since this binary isn't critical for the XRay runtime testing effort anymore (yet), we remove it in the meantime with the hope of moving the functionality in LLVM proper instead. Reviewers: kpw, pelikan, rnk, seurer, eugenis Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D31926 llvm-svn: 299916
* [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
* [XRay][compiler-rt] Remove dependency on <system_error>Dean Michael Berris2017-03-221-17/+18
| | | | | | | | | | | | | | | | | | Summary: Depending on C++11 <system_error> introduces a link-time requirement to C++11 symbols. Removing it allows us to depend on header-only C++11 and up libraries. Partially fixes http://llvm.org/PR32274 -- we know there's more invasive work to be done, but we're doing it incrementally. Reviewers: dblaikie, kpw, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31233 llvm-svn: 298480
* [XRay][compiler-rt] Add missing include for <functional>Dean Michael Berris2017-03-171-0/+1
| | | | | | Fixes http://llvm.org/PR32313 llvm-svn: 298037
* [XRay] [compiler-rt] Refactor logic for xray fdr logging. NFC.Dean Michael Berris2017-03-152-0/+331
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Unbreak unittest after r295967.Benjamin Kramer2017-02-231-2/+2
| | | | llvm-svn: 295969
* [XRay] Fix gtest error code comparison. NFC.Tim Shen2017-02-151-4/+8
| | | | llvm-svn: 295248
* [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][NFC] Turn ProudCase functions to humbleCase functionsDean Michael Berris2017-02-071-12/+12
| | | | | | | | | | | | | | | 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] XRay Flight Data Recorder ModeDean Michael Berris2017-01-254-10/+169
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-034-169/+10
| | | | | | This reverts rL290852 as it breaks aarch64 and arm. llvm-svn: 290854
* [XRay][compiler-rt] XRay Flight Data Recorder ModeDean Michael Berris2017-01-034-10/+169
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Use explicit comparisons in unit tests.Dean Michael Berris2016-12-131-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This should improve the error messages generated providing a bit more information when the failures are printed out. One example of a contrived error looks like: ``` Expected: (Buffers.getBuffer(Buf)) != (std::error_code()), actual: system:0 vs system:0 ``` Because we're using error codes, the default printing gets us more useful information in case of failure. This is a follow-up on D26232. Reviewers: rSerge Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27495 llvm-svn: 289501
* [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-064-0/+158
| | | | | | | | | | | | | | | | | | | | | | | | 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-254-158/+0
| | | | | | Broke the build on arm7 and aarch64. llvm-svn: 287911
* [XRay][compiler-rt] XRay Buffer QueueDean Michael Berris2016-11-254-0/+158
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