[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
|
|
|
//===- llvm/unittest/XRay/FDRTraceWriterTest.cpp ----------------*- C++ -*-===//
|
|
|
|
//
|
2019-01-19 09:50:56 +01: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 09:22:21 +02: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)
|
2018-09-11 08:36:51 +02: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 09:22:21 +02: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.
|
2018-08-31 18:08:38 +02: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 09:22:21 +02:00
|
|
|
auto TraceOrErr = loadTrace(DE, true);
|
|
|
|
if (!TraceOrErr)
|
|
|
|
FAIL() << TraceOrErr.takeError();
|
|
|
|
auto &Trace = TraceOrErr.get();
|
|
|
|
|
|
|
|
ASSERT_THAT(Trace, Not(IsEmpty()));
|
2018-08-31 21:32:46 +02:00
|
|
|
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::FuncId, Eq(1)),
|
2018-08-31 20:56:42 +02:00
|
|
|
Field(&XRayRecord::FuncId, Eq(1))));
|
2018-08-31 21:32:46 +02:00
|
|
|
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::TId, Eq(1u)),
|
2018-08-31 20:56:42 +02:00
|
|
|
Field(&XRayRecord::TId, Eq(1u))));
|
2018-08-31 21:32:46 +02:00
|
|
|
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::PId, Eq(1u)),
|
2018-08-31 20:56:42 +02:00
|
|
|
Field(&XRayRecord::PId, Eq(1u))));
|
2018-08-31 21:32:46 +02:00
|
|
|
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::CPU, Eq(1u)),
|
2018-08-31 20:56:42 +02:00
|
|
|
Field(&XRayRecord::CPU, Eq(1u))));
|
2018-08-31 21:32:46 +02:00
|
|
|
EXPECT_THAT(Trace,
|
2018-08-31 20:56:42 +02: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 09:22:21 +02: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)
|
2018-09-11 08:36:51 +02: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 09:22:21 +02: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.
|
2018-08-31 18:08:38 +02: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 09:22:21 +02:00
|
|
|
auto TraceOrErr = loadTrace(DE, true);
|
|
|
|
if (!TraceOrErr)
|
|
|
|
FAIL() << TraceOrErr.takeError();
|
|
|
|
auto &Trace = TraceOrErr.get();
|
|
|
|
|
|
|
|
ASSERT_THAT(Trace, Not(IsEmpty()));
|
2018-08-31 21:32:46 +02:00
|
|
|
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::FuncId, Eq(1)),
|
2018-08-31 20:56:42 +02:00
|
|
|
Field(&XRayRecord::FuncId, Eq(1))));
|
2018-08-31 21:32:46 +02:00
|
|
|
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::TId, Eq(1u)),
|
2018-08-31 20:56:42 +02:00
|
|
|
Field(&XRayRecord::TId, Eq(1u))));
|
2018-08-31 21:32:46 +02:00
|
|
|
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::CPU, Eq(1u)),
|
2018-08-31 20:56:42 +02:00
|
|
|
Field(&XRayRecord::CPU, Eq(1u))));
|
2018-08-31 21:32:46 +02:00
|
|
|
EXPECT_THAT(Trace,
|
2018-08-31 20:56:42 +02: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 09:22:21 +02: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);
|
2018-08-31 12:03:52 +02: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 09:22:21 +02:00
|
|
|
auto L = LogBuilder()
|
|
|
|
.add<NewBufferRecord>(1)
|
|
|
|
.add<WallclockRecord>(1, 1)
|
2018-09-11 08:36:51 +02: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 09:22:21 +02: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();
|
|
|
|
|
2018-08-31 12:03:52 +02: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 09:22:21 +02:00
|
|
|
// Then from here we load the Trace file.
|
2018-08-31 18:08:38 +02: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 09:22:21 +02:00
|
|
|
auto TraceOrErr = loadTrace(DE, true);
|
|
|
|
if (!TraceOrErr)
|
|
|
|
FAIL() << TraceOrErr.takeError();
|
|
|
|
auto &Trace = TraceOrErr.get();
|
|
|
|
|
|
|
|
ASSERT_THAT(Trace, Not(IsEmpty()));
|
2018-08-31 21:32:46 +02:00
|
|
|
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::FuncId, Eq(1)),
|
2018-08-31 20:56:42 +02:00
|
|
|
Field(&XRayRecord::FuncId, Eq(1))));
|
2018-08-31 21:32:46 +02:00
|
|
|
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::TId, Eq(1u)),
|
2018-08-31 20:56:42 +02:00
|
|
|
Field(&XRayRecord::TId, Eq(1u))));
|
2018-08-31 21:32:46 +02:00
|
|
|
EXPECT_THAT(Trace, ElementsAre(Field(&XRayRecord::CPU, Eq(1u)),
|
2018-08-31 20:56:42 +02:00
|
|
|
Field(&XRayRecord::CPU, Eq(1u))));
|
2018-08-31 21:32:46 +02:00
|
|
|
EXPECT_THAT(Trace,
|
2018-08-31 20:56:42 +02: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 09:22:21 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace
|
|
|
|
} // namespace xray
|
|
|
|
} // namespace llvm
|