maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/XRay/CMakeLists.txt

26 lines
431 B
CMake
Raw Normal View History

[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 14:39:09 +08:00
add_llvm_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 13:55:57 +08:00
BlockIndexer.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 16:04:56 +08: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 15:22:21 +08:00
FDRRecords.cpp
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 15:37:55 +08: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 08:05:29 +08: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 16:04:56 +08: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 15:22:21 +08: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 14:57:23 +08: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 14:39:09 +08:00
Trace.cpp
ADDITIONAL_HEADER_DIRS
${LLVM_MAIN_INCLUDE_DIR}/llvm/ADT
${LLVM_MAIN_INCLUDE_DIR}/llvm/XRay
DEPENDS
LLVMSupport
[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 08:05:29 +08:00
LLVMObject
[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 14:39:09 +08:00
LINK_LIBS
LLVMSupport
[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 08:05:29 +08:00
LLVMObject
[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 14:39:09 +08:00
)