llvm-mirror/lib/XRay/CMakeLists.txt

add_llvm_component_library(LLVMXRay
  BlockIndexer.cpp
  BlockPrinter.cpp
  BlockVerifier.cpp
  FDRRecordProducer.cpp
  FDRRecords.cpp
  FDRTraceExpander.cpp
  FDRTraceWriter.cpp
  FileHeaderReader.cpp
  InstrumentationMap.cpp
  LogBuilderConsumer.cpp
  Profile.cpp
  RecordInitializer.cpp
  RecordPrinter.cpp
  Trace.cpp

  ADDITIONAL_HEADER_DIRS
  ${LLVM_MAIN_INCLUDE_DIR}/llvm/ADT
  ${LLVM_MAIN_INCLUDE_DIR}/llvm/XRay
  )
[cmake] Explicitly mark libraries defined in lib/ as "Component Libraries" Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179 2019-11-14 06:39:58 +01:00			`add_llvm_component_library(LLVMXRay`
[XRay] Add a BlockIndexer visitor for FDR Records. Summary: This change adds a `BlockIndexer` type which maintains pointers to records that belong to the same process+thread pairs. The indexing happens with order of appearance of records as they are visited. This version of the indexer currently only supports FDR version 3 logs, which contain `BufferExtent` records. We will add support for v2 and v1 logs in follow-up patches. This is another part of D50441. Reviewers: eizan, kpw, mboerger Reviewed By: mboerger Subscribers: mboerger, mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51673 llvm-svn: 341518 2018-09-06 07:55:57 +02:00			`BlockIndexer.cpp`
[XRay] Add the `llvm-xray fdr-dump` implementation Summary: In this change, we implement a `BlockPrinter` which orders records in a Block that's been indexed by the `BlockIndexer`. This is used in the `llvm-xray fdr-dump` tool which ties together the various types and utilities we've been working on, to allow for inspection of XRay FDR mode traces both with and without verification. This change is the final step of the refactoring of D50441. Reviewers: mboerger, eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51846 llvm-svn: 341887 2018-09-11 02:22:53 +02:00			`BlockPrinter.cpp`
[XRay] Add a BlockVerifier visitor for FDR Records Summary: This patch implements a `BlockVerifier` type which enforces the invariants of the log structure of FDR mode logs on a per-block basis. This ensures that the data we encounter from an FDR mode log semantically correct (i.e. that records follow the documented "grammar" for FDR mode log records). This is another part of the refactoring of D50441. This is a slightly modified version of rL341628, avoiding the `std::tuple<...>` constructor that is not constexpr in C++11. Reviewers: mboerger, eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51723 llvm-svn: 341769 2018-09-10 04:35:25 +02:00			`BlockVerifier.cpp`
[XRay] FDR Record Producer/Consumer Implementation Summary: This patch defines two new base types called `RecordProducer` and `RecordConsumer` which have default implementations for convenience (particularly for testing). A `RecordProducer` implementation has one member function called `produce()` which serves as a factory constructor for `Record` instances. This code exercises the `RecordInitializer` code path in the implementation for `FileBasedRecordProducer`. A `RecordConsumer` has a single member function called `consume(...)` which, as the name implies, consumes instances of `std::unique_ptr<Record>`. We have two implementations, one of which is used in the test to generate a vector of `std::unique_ptr<Record>` similar to how the `LogBuilder` implementation works. We introduce a test in `FDRProducerConsumerTest` which ensures that records we write through the `FDRTraceWriter` can be loaded by the `FileBasedRecordProducer`. The record(s) loaded this way are written again through the `FDRTraceWriter` into a separate string, which we then compare. This ensures that the read-in bytes to create the `Record` instances in memory can be replicated when written out through the `FDRTraceWriter`. This change depends on D51210 and is part of the refactoring of D50441 into smaller, more focused changes. Reviewers: eizan, kpw Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51289 llvm-svn: 341180 2018-08-31 10:04:56 +02:00			`FDRRecordProducer.cpp`
[XRay] FDRTraceWriter and FDR Trace Loading Summary: This is the first step in the larger refactoring and reduction of D50441. This step in the process does the following: - Introduces more granular types of `Record`s representing the many kinds of records written/read by the Flight Data Recorder (FDR) mode `Trace` loading function(s). - Introduces an abstract `RecordVisitor` type meant to handle the processing of the various `Record` derived types. This `RecordVisitor` has two implementations in this patch: `RecordInitializer` and `FDRTraceWriter`. - We also introduce a convenience interface for building a collection of `Record` instances called a `LogBuilder`. This allows us to generate sequences of `Record` instances manually (used in unit tests but useful otherwise). - The`FDRTraceWriter` class implements the `RecordVisitor` interface and handles the writing of metadata records to a `raw_ostream`. We demonstrate that in the unit test, we can generate in-memory FDR mode traces using the specific `Record` derived types, which we load through the `loadTrace(...)` function yielding valid `Trace` objects. This patch introduces the required types and concepts for us to start replacing the logic implemented in the `loadFDRLog` function to use the more granular types. In subsequent patches, we will introduce more visitor implementations which isolate the verification, printing, indexing, production/consumption, and finally the conversion of the FDR mode logs. The overarching goal of these changes is to make handling FDR mode logs better tested, more understandable, more extensible, and more systematic. This will also allow us to better represent the execution trace, as we improve the fidelity of the events we represent in an XRay `Trace` object, which we intend to do after FDR mode log processing is in better shape. Reviewers: eizan Reviewed By: eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51210 llvm-svn: 341029 2018-08-30 09:22:21 +02:00			`FDRRecords.cpp`
[XRay] Use FDR Records+Visitors for Trace Loading Summary: In this change, we overhaul the implementation for loading `llvm::xray::Trace` objects from files by using the combination of specific FDR Record types and visitors breaking up the logic to reconstitute an execution trace from flight-data recorder mode traces. This change allows us to handle out-of-temporal order blocks as written in files, and more consistently recreate an execution trace spanning multiple blocks and threads. To do this, we use the `WallclockRecord` associated with each block to maintain temporal order of blocks, before attempting to recreate an execution trace. The new addition in this change is the `TraceExpander` type which can be thought of as a decompression/decoding routine. This allows us to maintain the state of an execution environment (thread+process) and create `XRayRecord` instances that fit nicely into the `Trace` container. We don't have a specific unit test for the TraceExpander type, since the end-to-end tests for the `llvm-xray convert` tools already cover precisely this codepath. This change completes the refactoring started with D50441. Depends on D51911. Reviewers: mboerger, eizan Subscribers: mgorny, hiraditya, mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D51912 llvm-svn: 341906 2018-09-11 08:45:59 +02:00			`FDRTraceExpander.cpp`
[XRay] FDRTraceWriter and FDR Trace Loading Summary: This is the first step in the larger refactoring and reduction of D50441. This step in the process does the following: - Introduces more granular types of `Record`s representing the many kinds of records written/read by the Flight Data Recorder (FDR) mode `Trace` loading function(s). - Introduces an abstract `RecordVisitor` type meant to handle the processing of the various `Record` derived types. This `RecordVisitor` has two implementations in this patch: `RecordInitializer` and `FDRTraceWriter`. - We also introduce a convenience interface for building a collection of `Record` instances called a `LogBuilder`. This allows us to generate sequences of `Record` instances manually (used in unit tests but useful otherwise). - The`FDRTraceWriter` class implements the `RecordVisitor` interface and handles the writing of metadata records to a `raw_ostream`. We demonstrate that in the unit test, we can generate in-memory FDR mode traces using the specific `Record` derived types, which we load through the `loadTrace(...)` function yielding valid `Trace` objects. This patch introduces the required types and concepts for us to start replacing the logic implemented in the `loadFDRLog` function to use the more granular types. In subsequent patches, we will introduce more visitor implementations which isolate the verification, printing, indexing, production/consumption, and finally the conversion of the FDR mode logs. The overarching goal of these changes is to make handling FDR mode logs better tested, more understandable, more extensible, and more systematic. This will also allow us to better represent the execution trace, as we improve the fidelity of the events we represent in an XRay `Trace` object, which we intend to do after FDR mode log processing is in better shape. Reviewers: eizan Reviewed By: eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51210 llvm-svn: 341029 2018-08-30 09:22:21 +02:00			`FDRTraceWriter.cpp`
[XRay] Refactor file header reading (NFC) Summary: This patch moves out the definition of the XRay log file header from binary logs into its own header and implementation file. This is one part of the refactoring being done in D50441. Reviewers: eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51086 llvm-svn: 340389 2018-08-22 09:37:55 +02:00			`FileHeaderReader.cpp`
[XRay] Define the InstrumentationMap type Summary: This change implements the instrumentation map loading library which can understand both YAML-defined instrumentation maps, and ELF 64-bit object files that have the XRay instrumentation map section. We break it out into a library on its own to allow for other applications to deal with the XRay instrumentation map defined in XRay-instrumented binaries. This type provides both raw access to the logical representation of the instrumentation map entries as well as higher level functions for converting a function ID into a function address. At this point we only support ELF64 binaries and YAML-defined XRay instrumentation maps. Future changes should extend this to support 32-bit ELF binaries, as well as other binary formats (like MachO). As part of this change we also migrate all uses of the extraction logic that used to be defined in tools/llvm-xray/ to use this new type and interface for loading from files. We also remove the flag from the `llvm-xray` tool that required users to specify the type of the instrumentation map file being provided to instead make the library auto-detect the file type. Reviewers: dblaikie Subscribers: mgorny, varno, llvm-commits Differential Revision: https://reviews.llvm.org/D29319 llvm-svn: 293721 2017-02-01 01:05:29 +01:00			`InstrumentationMap.cpp`
[XRay] FDR Record Producer/Consumer Implementation Summary: This patch defines two new base types called `RecordProducer` and `RecordConsumer` which have default implementations for convenience (particularly for testing). A `RecordProducer` implementation has one member function called `produce()` which serves as a factory constructor for `Record` instances. This code exercises the `RecordInitializer` code path in the implementation for `FileBasedRecordProducer`. A `RecordConsumer` has a single member function called `consume(...)` which, as the name implies, consumes instances of `std::unique_ptr<Record>`. We have two implementations, one of which is used in the test to generate a vector of `std::unique_ptr<Record>` similar to how the `LogBuilder` implementation works. We introduce a test in `FDRProducerConsumerTest` which ensures that records we write through the `FDRTraceWriter` can be loaded by the `FileBasedRecordProducer`. The record(s) loaded this way are written again through the `FDRTraceWriter` into a separate string, which we then compare. This ensures that the read-in bytes to create the `Record` instances in memory can be replicated when written out through the `FDRTraceWriter`. This change depends on D51210 and is part of the refactoring of D50441 into smaller, more focused changes. Reviewers: eizan, kpw Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51289 llvm-svn: 341180 2018-08-31 10:04:56 +02:00			`LogBuilderConsumer.cpp`
[XRay] FDRTraceWriter and FDR Trace Loading Summary: This is the first step in the larger refactoring and reduction of D50441. This step in the process does the following: - Introduces more granular types of `Record`s representing the many kinds of records written/read by the Flight Data Recorder (FDR) mode `Trace` loading function(s). - Introduces an abstract `RecordVisitor` type meant to handle the processing of the various `Record` derived types. This `RecordVisitor` has two implementations in this patch: `RecordInitializer` and `FDRTraceWriter`. - We also introduce a convenience interface for building a collection of `Record` instances called a `LogBuilder`. This allows us to generate sequences of `Record` instances manually (used in unit tests but useful otherwise). - The`FDRTraceWriter` class implements the `RecordVisitor` interface and handles the writing of metadata records to a `raw_ostream`. We demonstrate that in the unit test, we can generate in-memory FDR mode traces using the specific `Record` derived types, which we load through the `loadTrace(...)` function yielding valid `Trace` objects. This patch introduces the required types and concepts for us to start replacing the logic implemented in the `loadFDRLog` function to use the more granular types. In subsequent patches, we will introduce more visitor implementations which isolate the verification, printing, indexing, production/consumption, and finally the conversion of the FDR mode logs. The overarching goal of these changes is to make handling FDR mode logs better tested, more understandable, more extensible, and more systematic. This will also allow us to better represent the execution trace, as we improve the fidelity of the events we represent in an XRay `Trace` object, which we intend to do after FDR mode log processing is in better shape. Reviewers: eizan Reviewed By: eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51210 llvm-svn: 341029 2018-08-30 09:22:21 +02:00			`Profile.cpp`
			`RecordInitializer.cpp`
[XRay] Add a RecordPrinter visitor for FDR Records Summary: This change adds a `RecordPrinter` type which does some basic text serialization of the FDR record instances. This is one component of the tool we're building to dump the records from an FDR mode log as-is. This is a small part of D50441. Reviewers: eizan, kpw Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51672 llvm-svn: 341447 2018-09-05 08:57:23 +02:00			`RecordPrinter.cpp`
[XRay] Define the library for XRay trace logs Summary: In this change we move the definition of the log reading routines from the tools directory in LLVM to {include/llvm,lib}/XRay. We improve the documentation a little bit for the publicly accessible headers, and adjust the top-matter. This also leads to some refactoring and cleanup in the tooling code. In particular, we do the following: - Rename the class from LogReader to Trace, as it better represents the logical set of records as opposed to a log. - Use file type detection instead of asking the user to say what format the input file is. This allows us to keep the interface simple and encapsulate the logic of loading the data appropriately. In future changes we increase the API surface and write dedicated unit tests for the XRay library. Depends on D24376. Reviewers: dblaikie, echristo Subscribers: mehdi_amini, mgorny, llvm-commits, varno Differential Revision: https://reviews.llvm.org/D28345 llvm-svn: 291652 2017-01-11 07:39:09 +01:00			`Trace.cpp`

			`ADDITIONAL_HEADER_DIRS`
			`${LLVM_MAIN_INCLUDE_DIR}/llvm/ADT`
			`${LLVM_MAIN_INCLUDE_DIR}/llvm/XRay`
			`)`