maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/unittests/XRay/FDRTraceWriterTest.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

183 lines
6.6 KiB
C++
Raw Normal View History

[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
//===- llvm/unittest/XRay/FDRTraceWriterTest.cpp ----------------*- C++ -*-===//
//
Update the file headers across all of the LLVM projects in the monorepo 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
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
[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
//
//===----------------------------------------------------------------------===//
//
// Test a utility that can write out XRay FDR Mode formatted trace files.
//
//===----------------------------------------------------------------------===//
#include "llvm/XRay/FDRTraceWriter.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/XRay/FDRLogBuilder.h"
#include "llvm/XRay/FDRRecords.h"
#include "llvm/XRay/Trace.h"
#include "gmock/gmock.h"
#include "gtest/gtest.h"
#include <string>
namespace llvm {
namespace xray {
namespace {
using testing::ElementsAre;
using testing::Eq;
using testing::Field;
using testing::IsEmpty;
using testing::Not;
// We want to be able to create an instance of an FDRTraceWriter and associate
// it with a stream, which could be loaded and turned into a Trace instance.
// This test writes out version 3 trace logs.
TEST(FDRTraceWriterTest, WriteToStringBufferVersion3) {
std::string Data;
raw_string_ostream OS(Data);
XRayFileHeader H;
H.Version = 3;
H.Type = 1;
H.ConstantTSC = true;
H.NonstopTSC = true;
H.CycleFrequency = 3e9;
FDRTraceWriter Writer(OS, H);
auto L = LogBuilder()
.add<BufferExtents>(80)
.add<NewBufferRecord>(1)
.add<WallclockRecord>(1, 1)
.add<PIDRecord>(1)
[XRay] Add TSC to NewCPUId Records Summary: This more correctly reflects the data written by the FDR mode runtime. This is a continuation of the work in D50441. Reviewers: mboerger, eizan Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51911 llvm-svn: 341905
2018-09-11 14:36:51 +08:00
.add<NewCPUIDRecord>(1, 2)
[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
.add<FunctionRecord>(RecordTypes::ENTER, 1, 1)
.add<FunctionRecord>(RecordTypes::EXIT, 1, 100)
.consume();
for (auto &P : L)
ASSERT_FALSE(errorToBool(P->apply(Writer)));
OS.flush();
// Then from here we load the Trace file.
[XRay] Make the FDRTraceWriter Endian-aware Before this patch, the FDRTraceWriter would not take endianness into account when writing data into the output stream. This is a follow-up to D51289 and D51210. llvm-svn: 341223
2018-09-01 00:08:38 +08:00
DataExtractor DE(Data, sys::IsLittleEndianHost, 8);
[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
auto TraceOrErr = loadTrace(DE, true);
if (!TraceOrErr)
FAIL() << TraceOrErr.takeError();
auto &Trace = TraceOrErr.get();
ASSERT_THAT(Trace, Not(IsEmpty()));
[XRay] Use correct type for PID records Previously we've been reading and writing the wrong types which only worked in little endian implementations. This time we're writing the same typed values the runtime is using, and reading them appropriately as well. llvm-svn: 341241
2018-09-01 03:32:46 +08:00
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::FuncId, Eq(1)),
[XRay] Improve test matching granularity (NFC) Simplify matchers for unittest to better isolate which differences there are that we're finding in failures. llvm-svn: 341237
2018-09-01 02:56:42 +08:00
Field(&XRayRecord::FuncId, Eq(1))));
[XRay] Use correct type for PID records Previously we've been reading and writing the wrong types which only worked in little endian implementations. This time we're writing the same typed values the runtime is using, and reading them appropriately as well. llvm-svn: 341241
2018-09-01 03:32:46 +08:00
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::TId, Eq(1u)),
[XRay] Improve test matching granularity (NFC) Simplify matchers for unittest to better isolate which differences there are that we're finding in failures. llvm-svn: 341237
2018-09-01 02:56:42 +08:00
Field(&XRayRecord::TId, Eq(1u))));
[XRay] Use correct type for PID records Previously we've been reading and writing the wrong types which only worked in little endian implementations. This time we're writing the same typed values the runtime is using, and reading them appropriately as well. llvm-svn: 341241
2018-09-01 03:32:46 +08:00
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::PId, Eq(1u)),
[XRay] Improve test matching granularity (NFC) Simplify matchers for unittest to better isolate which differences there are that we're finding in failures. llvm-svn: 341237
2018-09-01 02:56:42 +08:00
Field(&XRayRecord::PId, Eq(1u))));
[XRay] Use correct type for PID records Previously we've been reading and writing the wrong types which only worked in little endian implementations. This time we're writing the same typed values the runtime is using, and reading them appropriately as well. llvm-svn: 341241
2018-09-01 03:32:46 +08:00
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::CPU, Eq(1u)),
[XRay] Improve test matching granularity (NFC) Simplify matchers for unittest to better isolate which differences there are that we're finding in failures. llvm-svn: 341237
2018-09-01 02:56:42 +08:00
Field(&XRayRecord::CPU, Eq(1u))));
[XRay] Use correct type for PID records Previously we've been reading and writing the wrong types which only worked in little endian implementations. This time we're writing the same typed values the runtime is using, and reading them appropriately as well. llvm-svn: 341241
2018-09-01 03:32:46 +08:00
EXPECT_THAT(Trace,
[XRay] Improve test matching granularity (NFC) Simplify matchers for unittest to better isolate which differences there are that we're finding in failures. llvm-svn: 341237
2018-09-01 02:56:42 +08:00
ElementsAre(Field(&XRayRecord::Type, Eq(RecordTypes::ENTER)),
Field(&XRayRecord::Type, Eq(RecordTypes::EXIT))));
[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
}
// This version is almost exactly the same as above, except writing version 2
// logs, without the PID records.
TEST(FDRTraceWriterTest, WriteToStringBufferVersion2) {
std::string Data;
raw_string_ostream OS(Data);
XRayFileHeader H;
H.Version = 2;
H.Type = 1;
H.ConstantTSC = true;
H.NonstopTSC = true;
H.CycleFrequency = 3e9;
FDRTraceWriter Writer(OS, H);
auto L = LogBuilder()
.add<BufferExtents>(64)
.add<NewBufferRecord>(1)
.add<WallclockRecord>(1, 1)
[XRay] Add TSC to NewCPUId Records Summary: This more correctly reflects the data written by the FDR mode runtime. This is a continuation of the work in D50441. Reviewers: mboerger, eizan Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51911 llvm-svn: 341905
2018-09-11 14:36:51 +08:00
.add<NewCPUIDRecord>(1, 2)
[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
.add<FunctionRecord>(RecordTypes::ENTER, 1, 1)
.add<FunctionRecord>(RecordTypes::EXIT, 1, 100)
.consume();
for (auto &P : L)
ASSERT_FALSE(errorToBool(P->apply(Writer)));
OS.flush();
// Then from here we load the Trace file.
[XRay] Make the FDRTraceWriter Endian-aware Before this patch, the FDRTraceWriter would not take endianness into account when writing data into the output stream. This is a follow-up to D51289 and D51210. llvm-svn: 341223
2018-09-01 00:08:38 +08:00
DataExtractor DE(Data, sys::IsLittleEndianHost, 8);
[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
auto TraceOrErr = loadTrace(DE, true);
if (!TraceOrErr)
FAIL() << TraceOrErr.takeError();
auto &Trace = TraceOrErr.get();
ASSERT_THAT(Trace, Not(IsEmpty()));
[XRay] Use correct type for PID records Previously we've been reading and writing the wrong types which only worked in little endian implementations. This time we're writing the same typed values the runtime is using, and reading them appropriately as well. llvm-svn: 341241
2018-09-01 03:32:46 +08:00
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::FuncId, Eq(1)),
[XRay] Improve test matching granularity (NFC) Simplify matchers for unittest to better isolate which differences there are that we're finding in failures. llvm-svn: 341237
2018-09-01 02:56:42 +08:00
Field(&XRayRecord::FuncId, Eq(1))));
[XRay] Use correct type for PID records Previously we've been reading and writing the wrong types which only worked in little endian implementations. This time we're writing the same typed values the runtime is using, and reading them appropriately as well. llvm-svn: 341241
2018-09-01 03:32:46 +08:00
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::TId, Eq(1u)),
[XRay] Improve test matching granularity (NFC) Simplify matchers for unittest to better isolate which differences there are that we're finding in failures. llvm-svn: 341237
2018-09-01 02:56:42 +08:00
Field(&XRayRecord::TId, Eq(1u))));
[XRay] Use correct type for PID records Previously we've been reading and writing the wrong types which only worked in little endian implementations. This time we're writing the same typed values the runtime is using, and reading them appropriately as well. llvm-svn: 341241
2018-09-01 03:32:46 +08:00
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::CPU, Eq(1u)),
[XRay] Improve test matching granularity (NFC) Simplify matchers for unittest to better isolate which differences there are that we're finding in failures. llvm-svn: 341237
2018-09-01 02:56:42 +08:00
Field(&XRayRecord::CPU, Eq(1u))));
[XRay] Use correct type for PID records Previously we've been reading and writing the wrong types which only worked in little endian implementations. This time we're writing the same typed values the runtime is using, and reading them appropriately as well. llvm-svn: 341241
2018-09-01 03:32:46 +08:00
EXPECT_THAT(Trace,
[XRay] Improve test matching granularity (NFC) Simplify matchers for unittest to better isolate which differences there are that we're finding in failures. llvm-svn: 341237
2018-09-01 02:56:42 +08:00
ElementsAre(Field(&XRayRecord::Type, Eq(RecordTypes::ENTER)),
Field(&XRayRecord::Type, Eq(RecordTypes::EXIT))));
[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
}
// This covers version 1 of the log, without a BufferExtents record but has an
// explicit EndOfBuffer record.
TEST(FDRTraceWriterTest, WriteToStringBufferVersion1) {
std::string Data;
raw_string_ostream OS(Data);
XRayFileHeader H;
H.Version = 1;
H.Type = 1;
H.ConstantTSC = true;
H.NonstopTSC = true;
H.CycleFrequency = 3e9;
// Write the size of buffers out, arbitrarily it's 4k.
constexpr uint64_t BufferSize = 4096;
std::memcpy(H.FreeFormData, reinterpret_cast<const char *>(&BufferSize),
sizeof(BufferSize));
FDRTraceWriter Writer(OS, H);
[XRay] Attempt to fix failure on Windows Original version of the code relied on implementation-defined order of bitfields. Follow-up on D51210. llvm-svn: 341194
2018-08-31 18:03:52 +08:00
OS.flush();
// Ensure that at this point the Data buffer has the file header serialized
// size.
ASSERT_THAT(Data.size(), Eq(32u));
[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
auto L = LogBuilder()
.add<NewBufferRecord>(1)
.add<WallclockRecord>(1, 1)
[XRay] Add TSC to NewCPUId Records Summary: This more correctly reflects the data written by the FDR mode runtime. This is a continuation of the work in D50441. Reviewers: mboerger, eizan Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51911 llvm-svn: 341905
2018-09-11 14:36:51 +08:00
.add<NewCPUIDRecord>(1, 2)
[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
.add<FunctionRecord>(RecordTypes::ENTER, 1, 1)
.add<FunctionRecord>(RecordTypes::EXIT, 1, 100)
.add<EndBufferRecord>()
.consume();
for (auto &P : L)
ASSERT_FALSE(errorToBool(P->apply(Writer)));
// We need to pad the buffer with 4016 (4096 - 80) bytes of zeros.
OS.write_zeros(4016);
OS.flush();
[XRay] Attempt to fix failure on Windows Original version of the code relied on implementation-defined order of bitfields. Follow-up on D51210. llvm-svn: 341194
2018-08-31 18:03:52 +08:00
// For version 1 of the log, we need the whole buffer to be the size of the
// file header plus 32.
ASSERT_THAT(Data.size(), Eq(BufferSize + 32));
[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
// Then from here we load the Trace file.
[XRay] Make the FDRTraceWriter Endian-aware Before this patch, the FDRTraceWriter would not take endianness into account when writing data into the output stream. This is a follow-up to D51289 and D51210. llvm-svn: 341223
2018-09-01 00:08:38 +08:00
DataExtractor DE(Data, sys::IsLittleEndianHost, 8);
[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
auto TraceOrErr = loadTrace(DE, true);
if (!TraceOrErr)
FAIL() << TraceOrErr.takeError();
auto &Trace = TraceOrErr.get();
ASSERT_THAT(Trace, Not(IsEmpty()));
[XRay] Use correct type for PID records Previously we've been reading and writing the wrong types which only worked in little endian implementations. This time we're writing the same typed values the runtime is using, and reading them appropriately as well. llvm-svn: 341241
2018-09-01 03:32:46 +08:00
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::FuncId, Eq(1)),
[XRay] Improve test matching granularity (NFC) Simplify matchers for unittest to better isolate which differences there are that we're finding in failures. llvm-svn: 341237
2018-09-01 02:56:42 +08:00
Field(&XRayRecord::FuncId, Eq(1))));
[XRay] Use correct type for PID records Previously we've been reading and writing the wrong types which only worked in little endian implementations. This time we're writing the same typed values the runtime is using, and reading them appropriately as well. llvm-svn: 341241
2018-09-01 03:32:46 +08:00
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::TId, Eq(1u)),
[XRay] Improve test matching granularity (NFC) Simplify matchers for unittest to better isolate which differences there are that we're finding in failures. llvm-svn: 341237
2018-09-01 02:56:42 +08:00
Field(&XRayRecord::TId, Eq(1u))));
[XRay] Use correct type for PID records Previously we've been reading and writing the wrong types which only worked in little endian implementations. This time we're writing the same typed values the runtime is using, and reading them appropriately as well. llvm-svn: 341241
2018-09-01 03:32:46 +08:00
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::CPU, Eq(1u)),
[XRay] Improve test matching granularity (NFC) Simplify matchers for unittest to better isolate which differences there are that we're finding in failures. llvm-svn: 341237
2018-09-01 02:56:42 +08:00
Field(&XRayRecord::CPU, Eq(1u))));
[XRay] Use correct type for PID records Previously we've been reading and writing the wrong types which only worked in little endian implementations. This time we're writing the same typed values the runtime is using, and reading them appropriately as well. llvm-svn: 341241
2018-09-01 03:32:46 +08:00
EXPECT_THAT(Trace,
[XRay] Improve test matching granularity (NFC) Simplify matchers for unittest to better isolate which differences there are that we're finding in failures. llvm-svn: 341237
2018-09-01 02:56:42 +08:00
ElementsAre(Field(&XRayRecord::Type, Eq(RecordTypes::ENTER)),
Field(&XRayRecord::Type, Eq(RecordTypes::EXIT))));
[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
}
} // namespace
} // namespace xray
} // namespace llvm