[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
//===-- xray_fdr_controller.h ---------------------------------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file is a part of XRay, a function call tracing system.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#ifndef COMPILER_RT_LIB_XRAY_XRAY_FDR_CONTROLLER_H_
|
|
|
|
#define COMPILER_RT_LIB_XRAY_XRAY_FDR_CONTROLLER_H_
|
|
|
|
|
|
|
|
#include <time.h>
|
|
|
|
|
|
|
|
#include "xray/xray_interface.h"
|
|
|
|
#include "xray/xray_records.h"
|
|
|
|
#include "xray_buffer_queue.h"
|
|
|
|
#include "xray_fdr_log_writer.h"
|
|
|
|
|
|
|
|
namespace __xray {
|
|
|
|
|
|
|
|
template <size_t Version = 3> class FDRController {
|
|
|
|
BufferQueue *BQ;
|
|
|
|
BufferQueue::Buffer &B;
|
|
|
|
FDRLogWriter &W;
|
|
|
|
int (*WallClockReader)(clockid_t, struct timespec *) = 0;
|
|
|
|
uint64_t CycleThreshold = 0;
|
|
|
|
|
|
|
|
uint64_t LastFunctionEntryTSC = 0;
|
|
|
|
uint64_t LatestTSC = 0;
|
|
|
|
uint16_t LatestCPU = 0;
|
|
|
|
tid_t TId = 0;
|
|
|
|
pid_t PId = 0;
|
|
|
|
bool First = true;
|
|
|
|
|
|
|
|
uint32_t UndoableFunctionEnters = 0;
|
|
|
|
uint32_t UndoableTailExits = 0;
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
bool finalized() const XRAY_NEVER_INSTRUMENT {
|
|
|
|
return BQ == nullptr || BQ->finalizing();
|
|
|
|
}
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
bool hasSpace(size_t S) XRAY_NEVER_INSTRUMENT {
|
2018-10-27 11:00:21 +08:00
|
|
|
return B.Data != nullptr && B.Generation == BQ->generation() &&
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
W.getNextRecord() + S <= reinterpret_cast<char *>(B.Data) + B.Size;
|
|
|
|
}
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
constexpr int32_t mask(int32_t FuncId) const XRAY_NEVER_INSTRUMENT {
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
return FuncId & ((1 << 29) - 1);
|
|
|
|
}
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
bool getNewBuffer() XRAY_NEVER_INSTRUMENT {
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
if (BQ->getBuffer(B) != BufferQueue::ErrorCode::Ok)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
W.resetRecord();
|
|
|
|
DCHECK_EQ(W.getNextRecord(), B.Data);
|
|
|
|
LatestTSC = 0;
|
|
|
|
LatestCPU = 0;
|
2018-10-27 11:00:21 +08:00
|
|
|
First = true;
|
|
|
|
UndoableFunctionEnters = 0;
|
|
|
|
UndoableTailExits = 0;
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
atomic_store(&B.Extents, 0, memory_order_release);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
bool setupNewBuffer() XRAY_NEVER_INSTRUMENT {
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
if (finalized())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
DCHECK(hasSpace(sizeof(MetadataRecord) * 3));
|
|
|
|
TId = GetTid();
|
|
|
|
PId = internal_getpid();
|
|
|
|
struct timespec TS {
|
|
|
|
0, 0
|
|
|
|
};
|
|
|
|
WallClockReader(CLOCK_MONOTONIC, &TS);
|
|
|
|
|
|
|
|
MetadataRecord Metadata[] = {
|
|
|
|
// Write out a MetadataRecord to signify that this is the start of a new
|
|
|
|
// buffer, associated with a particular thread, with a new CPU. For the
|
|
|
|
// data, we have 15 bytes to squeeze as much information as we can. At
|
|
|
|
// this point we only write down the following bytes:
|
|
|
|
// - Thread ID (tid_t, cast to 4 bytes type due to Darwin being 8
|
|
|
|
// bytes)
|
|
|
|
createMetadataRecord<MetadataRecord::RecordKinds::NewBuffer>(
|
|
|
|
static_cast<int32_t>(TId)),
|
|
|
|
|
|
|
|
// Also write the WalltimeMarker record. We only really need microsecond
|
|
|
|
// precision here, and enforce across platforms that we need 64-bit
|
|
|
|
// seconds and 32-bit microseconds encoded in the Metadata record.
|
|
|
|
createMetadataRecord<MetadataRecord::RecordKinds::WalltimeMarker>(
|
|
|
|
static_cast<int64_t>(TS.tv_sec),
|
|
|
|
static_cast<int32_t>(TS.tv_nsec / 1000)),
|
|
|
|
|
|
|
|
// Also write the Pid record.
|
|
|
|
createMetadataRecord<MetadataRecord::RecordKinds::Pid>(
|
|
|
|
static_cast<int32_t>(PId)),
|
|
|
|
};
|
|
|
|
|
|
|
|
if (finalized())
|
|
|
|
return false;
|
|
|
|
return W.writeMetadataRecords(Metadata);
|
|
|
|
}
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
bool prepareBuffer(size_t S) XRAY_NEVER_INSTRUMENT {
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
if (finalized())
|
|
|
|
return returnBuffer();
|
|
|
|
|
|
|
|
if (UNLIKELY(!hasSpace(S))) {
|
2018-10-27 11:00:21 +08:00
|
|
|
if (!returnBuffer())
|
|
|
|
return false;
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
if (!getNewBuffer())
|
|
|
|
return false;
|
|
|
|
if (!setupNewBuffer())
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (First) {
|
|
|
|
First = false;
|
|
|
|
W.resetRecord();
|
|
|
|
atomic_store(&B.Extents, 0, memory_order_release);
|
|
|
|
return setupNewBuffer();
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
bool returnBuffer() XRAY_NEVER_INSTRUMENT {
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
if (BQ == nullptr)
|
|
|
|
return false;
|
|
|
|
|
2018-10-27 11:00:21 +08:00
|
|
|
First = true;
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
if (finalized()) {
|
|
|
|
BQ->releaseBuffer(B); // ignore result.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-10-27 11:00:21 +08:00
|
|
|
return BQ->releaseBuffer(B) == BufferQueue::ErrorCode::Ok;
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
}
|
|
|
|
|
2018-10-27 11:00:21 +08:00
|
|
|
enum class PreambleResult { NoChange, WroteMetadata, InvalidBuffer };
|
2018-10-30 12:35:48 +08:00
|
|
|
PreambleResult functionPreamble(uint64_t TSC,
|
|
|
|
uint16_t CPU) XRAY_NEVER_INSTRUMENT {
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
if (UNLIKELY(LatestCPU != CPU || LatestTSC == 0)) {
|
|
|
|
// We update our internal tracking state for the Latest TSC and CPU we've
|
|
|
|
// seen, then write out the appropriate metadata and function records.
|
|
|
|
LatestTSC = TSC;
|
|
|
|
LatestCPU = CPU;
|
2018-10-27 11:00:21 +08:00
|
|
|
|
|
|
|
if (B.Generation != BQ->generation())
|
|
|
|
return PreambleResult::InvalidBuffer;
|
|
|
|
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
W.writeMetadata<MetadataRecord::RecordKinds::NewCPUId>(CPU, TSC);
|
|
|
|
return PreambleResult::WroteMetadata;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (UNLIKELY(LatestCPU == LatestCPU && LatestTSC > TSC)) {
|
|
|
|
// The TSC has wrapped around, from the last TSC we've seen.
|
|
|
|
LatestTSC = TSC;
|
2018-10-27 11:00:21 +08:00
|
|
|
|
|
|
|
if (B.Generation != BQ->generation())
|
|
|
|
return PreambleResult::InvalidBuffer;
|
|
|
|
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
W.writeMetadata<MetadataRecord::RecordKinds::TSCWrap>(TSC);
|
|
|
|
return PreambleResult::WroteMetadata;
|
|
|
|
}
|
|
|
|
|
|
|
|
return PreambleResult::NoChange;
|
|
|
|
}
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
bool rewindRecords(int32_t FuncId, uint64_t TSC,
|
|
|
|
uint16_t CPU) XRAY_NEVER_INSTRUMENT {
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
// Undo one enter record, because at this point we are either at the state
|
|
|
|
// of:
|
|
|
|
// - We are exiting a function that we recently entered.
|
|
|
|
// - We are exiting a function that was the result of a sequence of tail
|
|
|
|
// exits, and we can check whether the tail exits can be re-wound.
|
|
|
|
//
|
|
|
|
FunctionRecord F;
|
|
|
|
W.undoWrites(sizeof(FunctionRecord));
|
2018-10-27 11:00:21 +08:00
|
|
|
if (B.Generation != BQ->generation())
|
|
|
|
return false;
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
internal_memcpy(&F, W.getNextRecord(), sizeof(FunctionRecord));
|
|
|
|
|
|
|
|
DCHECK(F.RecordKind ==
|
|
|
|
uint8_t(FunctionRecord::RecordKinds::FunctionEnter) &&
|
|
|
|
"Expected to find function entry recording when rewinding.");
|
|
|
|
DCHECK_EQ(F.FuncId, FuncId & ~(0x0F << 28));
|
|
|
|
|
|
|
|
LatestTSC -= F.TSCDelta;
|
|
|
|
if (--UndoableFunctionEnters != 0) {
|
|
|
|
LastFunctionEntryTSC -= F.TSCDelta;
|
2018-10-27 11:00:21 +08:00
|
|
|
return true;
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
LastFunctionEntryTSC = 0;
|
|
|
|
auto RewindingTSC = LatestTSC;
|
|
|
|
auto RewindingRecordPtr = W.getNextRecord() - sizeof(FunctionRecord);
|
|
|
|
while (UndoableTailExits) {
|
2018-10-27 11:00:21 +08:00
|
|
|
if (B.Generation != BQ->generation())
|
|
|
|
return false;
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
internal_memcpy(&F, RewindingRecordPtr, sizeof(FunctionRecord));
|
|
|
|
DCHECK_EQ(F.RecordKind,
|
|
|
|
uint8_t(FunctionRecord::RecordKinds::FunctionTailExit));
|
|
|
|
RewindingTSC -= F.TSCDelta;
|
|
|
|
RewindingRecordPtr -= sizeof(FunctionRecord);
|
2018-10-27 11:00:21 +08:00
|
|
|
if (B.Generation != BQ->generation())
|
|
|
|
return false;
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
internal_memcpy(&F, RewindingRecordPtr, sizeof(FunctionRecord));
|
|
|
|
|
|
|
|
// This tail call exceeded the threshold duration. It will not be erased.
|
|
|
|
if ((TSC - RewindingTSC) >= CycleThreshold) {
|
|
|
|
UndoableTailExits = 0;
|
2018-10-27 11:00:21 +08:00
|
|
|
return true;
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
--UndoableTailExits;
|
|
|
|
W.undoWrites(sizeof(FunctionRecord) * 2);
|
|
|
|
LatestTSC = RewindingTSC;
|
|
|
|
}
|
2018-10-27 11:00:21 +08:00
|
|
|
return true;
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
public:
|
|
|
|
template <class WallClockFunc>
|
|
|
|
FDRController(BufferQueue *BQ, BufferQueue::Buffer &B, FDRLogWriter &W,
|
2018-10-30 12:35:48 +08:00
|
|
|
WallClockFunc R, uint64_t C) XRAY_NEVER_INSTRUMENT
|
|
|
|
: BQ(BQ),
|
|
|
|
B(B),
|
|
|
|
W(W),
|
|
|
|
WallClockReader(R),
|
|
|
|
CycleThreshold(C) {}
|
|
|
|
|
|
|
|
bool functionEnter(int32_t FuncId, uint64_t TSC,
|
|
|
|
uint16_t CPU) XRAY_NEVER_INSTRUMENT {
|
2018-10-27 11:00:21 +08:00
|
|
|
if (finalized() ||
|
|
|
|
!prepareBuffer(sizeof(MetadataRecord) + sizeof(FunctionRecord)))
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
return returnBuffer();
|
|
|
|
|
2018-10-27 11:00:21 +08:00
|
|
|
auto PreambleStatus = functionPreamble(TSC, CPU);
|
|
|
|
if (PreambleStatus == PreambleResult::InvalidBuffer)
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
return returnBuffer();
|
|
|
|
|
2018-10-27 11:00:21 +08:00
|
|
|
UndoableFunctionEnters = (PreambleStatus == PreambleResult::WroteMetadata)
|
|
|
|
? 1
|
|
|
|
: UndoableFunctionEnters + 1;
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
LastFunctionEntryTSC = TSC;
|
|
|
|
LatestTSC = TSC;
|
|
|
|
return W.writeFunction(FDRLogWriter::FunctionRecordKind::Enter,
|
|
|
|
mask(FuncId), TSC - LatestTSC);
|
|
|
|
}
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
bool functionTailExit(int32_t FuncId, uint64_t TSC,
|
|
|
|
uint16_t CPU) XRAY_NEVER_INSTRUMENT {
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
if (finalized())
|
|
|
|
return returnBuffer();
|
|
|
|
|
|
|
|
if (!prepareBuffer(sizeof(MetadataRecord) + sizeof(FunctionRecord)))
|
|
|
|
return returnBuffer();
|
|
|
|
|
2018-10-27 11:00:21 +08:00
|
|
|
auto PreambleStatus = functionPreamble(TSC, CPU);
|
|
|
|
if (PreambleStatus == PreambleResult::InvalidBuffer)
|
|
|
|
return returnBuffer();
|
|
|
|
|
|
|
|
if (PreambleStatus == PreambleResult::NoChange &&
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
UndoableFunctionEnters != 0 &&
|
2018-10-27 11:00:21 +08:00
|
|
|
TSC - LastFunctionEntryTSC < CycleThreshold)
|
|
|
|
return rewindRecords(FuncId, TSC, CPU);
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
|
|
|
|
UndoableTailExits = UndoableFunctionEnters ? UndoableTailExits + 1 : 0;
|
|
|
|
UndoableFunctionEnters = 0;
|
|
|
|
LatestTSC = TSC;
|
|
|
|
return W.writeFunction(FDRLogWriter::FunctionRecordKind::TailExit,
|
|
|
|
mask(FuncId), TSC - LatestTSC);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool functionEnterArg(int32_t FuncId, uint64_t TSC, uint16_t CPU,
|
2018-10-30 12:35:48 +08:00
|
|
|
uint64_t Arg) XRAY_NEVER_INSTRUMENT {
|
2018-10-27 11:00:21 +08:00
|
|
|
if (finalized() ||
|
|
|
|
!prepareBuffer((2 * sizeof(MetadataRecord)) + sizeof(FunctionRecord)) ||
|
|
|
|
functionPreamble(TSC, CPU) == PreambleResult::InvalidBuffer)
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
return returnBuffer();
|
|
|
|
|
|
|
|
LatestTSC = TSC;
|
|
|
|
LastFunctionEntryTSC = 0;
|
|
|
|
UndoableFunctionEnters = 0;
|
|
|
|
UndoableTailExits = 0;
|
|
|
|
|
|
|
|
W.writeFunction(FDRLogWriter::FunctionRecordKind::EnterArg, mask(FuncId),
|
|
|
|
TSC - LatestTSC);
|
|
|
|
return W.writeMetadata<MetadataRecord::RecordKinds::CallArgument>(Arg);
|
|
|
|
}
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
bool functionExit(int32_t FuncId, uint64_t TSC,
|
|
|
|
uint16_t CPU) XRAY_NEVER_INSTRUMENT {
|
2018-10-27 11:00:21 +08:00
|
|
|
if (finalized() ||
|
|
|
|
!prepareBuffer(sizeof(MetadataRecord) + sizeof(FunctionRecord)))
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
return returnBuffer();
|
|
|
|
|
2018-10-27 11:00:21 +08:00
|
|
|
auto PreambleStatus = functionPreamble(TSC, CPU);
|
|
|
|
if (PreambleStatus == PreambleResult::InvalidBuffer)
|
|
|
|
return returnBuffer();
|
|
|
|
|
|
|
|
if (PreambleStatus == PreambleResult::NoChange &&
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
UndoableFunctionEnters != 0 &&
|
2018-10-27 11:00:21 +08:00
|
|
|
TSC - LastFunctionEntryTSC < CycleThreshold)
|
|
|
|
return rewindRecords(FuncId, TSC, CPU);
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
|
2018-11-02 06:57:50 +08:00
|
|
|
auto Delta = TSC - LatestTSC;
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
LatestTSC = TSC;
|
|
|
|
UndoableFunctionEnters = 0;
|
|
|
|
UndoableTailExits = 0;
|
|
|
|
return W.writeFunction(FDRLogWriter::FunctionRecordKind::Exit, mask(FuncId),
|
2018-11-02 06:57:50 +08:00
|
|
|
Delta);
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
}
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
bool customEvent(uint64_t TSC, uint16_t CPU, const void *Event,
|
|
|
|
int32_t EventSize) XRAY_NEVER_INSTRUMENT {
|
|
|
|
if (finalized() ||
|
|
|
|
!prepareBuffer((2 * sizeof(MetadataRecord)) + EventSize) ||
|
|
|
|
functionPreamble(TSC, CPU) == PreambleResult::InvalidBuffer)
|
|
|
|
return returnBuffer();
|
|
|
|
|
|
|
|
LatestTSC = 0;
|
|
|
|
UndoableFunctionEnters = 0;
|
|
|
|
UndoableTailExits = 0;
|
2018-11-01 08:18:52 +08:00
|
|
|
return W.writeCustomEvent(TSC, CPU, Event, EventSize);
|
2018-10-30 12:35:48 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool typedEvent(uint64_t TSC, uint16_t CPU, uint16_t EventType,
|
|
|
|
const void *Event, int32_t EventSize) XRAY_NEVER_INSTRUMENT {
|
|
|
|
if (finalized() ||
|
|
|
|
!prepareBuffer((2 * sizeof(MetadataRecord)) + EventSize) ||
|
|
|
|
functionPreamble(TSC, CPU) == PreambleResult::InvalidBuffer)
|
|
|
|
return returnBuffer();
|
|
|
|
|
|
|
|
LatestTSC = 0;
|
|
|
|
UndoableFunctionEnters = 0;
|
|
|
|
UndoableTailExits = 0;
|
|
|
|
return W.writeTypedEvent(TSC, EventType, Event, EventSize);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool flush() XRAY_NEVER_INSTRUMENT {
|
[XRay][compiler-rt] FDR Mode Controller
Summary:
This change implements a controller for abstracting away the details of
what happens when tracing with FDR mode. This controller type allows us
to test in isolation the various cases where we're encountering function
entry, exit, and other kinds of events we are handling when FDR mode is
enabled.
This change introduces a number of testing facilities we've needed to
better support expressing the conditions we need for the unit tests. We
leave some TODOs for moving those utilities into the LLVM project,
sitting in the `Testing` library, to make matching conditions on XRay
`Trace` instances through googlemock more manageable and declarative.
We don't wire in the controller right away, to allow us to incrementally
update the implementation(s) as we increase testing coverage of the
controller type. There's a need to re-think the way we're managing
buffers in a multi-threaded environment, which is more invasive than
this implementation.
This step in the process allows us to encode our assumptions in the
implementation of the controller, and then evolve the buffer queue
implementation to support generational buffer management to ensure we
can continue to support the cases we're already supporting with the
controller.
Reviewers: mboerger, eizan
Subscribers: mgorny, llvm-commits, jfb
Differential Revision: https://reviews.llvm.org/D52588
llvm-svn: 344488
2018-10-15 10:57:06 +08:00
|
|
|
if (finalized()) {
|
|
|
|
returnBuffer(); // ignore result.
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return returnBuffer();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace __xray
|
|
|
|
|
|
|
|
#endif // COMPILER-RT_LIB_XRAY_XRAY_FDR_CONTROLLER_H_
|