2017-01-11 14:39:09 +08:00
|
|
|
//===- Trace.cpp - XRay Trace Loading implementation. ---------------------===//
|
2017-01-10 10:38:11 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2017-01-10 10:38:11 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// XRay log reader implementation.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
2017-01-11 14:39:09 +08:00
|
|
|
#include "llvm/XRay/Trace.h"
|
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2017-01-10 10:38:11 +08:00
|
|
|
#include "llvm/Support/DataExtractor.h"
|
2017-01-11 14:39:09 +08:00
|
|
|
#include "llvm/Support/Error.h"
|
2017-01-10 10:38:11 +08:00
|
|
|
#include "llvm/Support/FileSystem.h"
|
2018-09-11 14:45:59 +08:00
|
|
|
#include "llvm/XRay/BlockIndexer.h"
|
|
|
|
#include "llvm/XRay/BlockVerifier.h"
|
|
|
|
#include "llvm/XRay/FDRRecordConsumer.h"
|
|
|
|
#include "llvm/XRay/FDRRecordProducer.h"
|
|
|
|
#include "llvm/XRay/FDRRecords.h"
|
|
|
|
#include "llvm/XRay/FDRTraceExpander.h"
|
2018-08-22 15:37:55 +08:00
|
|
|
#include "llvm/XRay/FileHeaderReader.h"
|
2017-01-11 14:39:09 +08:00
|
|
|
#include "llvm/XRay/YAMLXRayRecord.h"
|
2018-09-11 14:45:59 +08:00
|
|
|
#include <memory>
|
|
|
|
#include <vector>
|
2017-01-10 10:38:11 +08:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
using namespace llvm::xray;
|
|
|
|
using llvm::yaml::Input;
|
|
|
|
|
2017-08-20 21:03:48 +08:00
|
|
|
namespace {
|
2017-01-11 14:39:09 +08:00
|
|
|
using XRayRecordStorage =
|
|
|
|
std::aligned_storage<sizeof(XRayRecord), alignof(XRayRecord)>::type;
|
2017-01-10 10:38:11 +08:00
|
|
|
|
2018-09-01 01:06:28 +08:00
|
|
|
Error loadNaiveFormatLog(StringRef Data, bool IsLittleEndian,
|
|
|
|
XRayFileHeader &FileHeader,
|
2017-02-17 09:47:16 +08:00
|
|
|
std::vector<XRayRecord> &Records) {
|
|
|
|
if (Data.size() < 32)
|
|
|
|
return make_error<StringError>(
|
|
|
|
"Not enough bytes for an XRay log.",
|
|
|
|
std::make_error_code(std::errc::invalid_argument));
|
|
|
|
|
|
|
|
if (Data.size() - 32 == 0 || Data.size() % 32 != 0)
|
|
|
|
return make_error<StringError>(
|
|
|
|
"Invalid-sized XRay data.",
|
|
|
|
std::make_error_code(std::errc::invalid_argument));
|
|
|
|
|
2018-09-01 01:06:28 +08:00
|
|
|
DataExtractor Reader(Data, IsLittleEndian, 8);
|
2018-08-07 12:42:39 +08:00
|
|
|
uint32_t OffsetPtr = 0;
|
2018-08-22 15:37:55 +08:00
|
|
|
auto FileHeaderOrError = readBinaryFormatHeader(Reader, OffsetPtr);
|
|
|
|
if (!FileHeaderOrError)
|
|
|
|
return FileHeaderOrError.takeError();
|
|
|
|
FileHeader = std::move(FileHeaderOrError.get());
|
2017-01-10 10:38:11 +08:00
|
|
|
|
|
|
|
// Each record after the header will be 32 bytes, in the following format:
|
|
|
|
//
|
|
|
|
// (2) uint16 : record type
|
|
|
|
// (1) uint8 : cpu id
|
|
|
|
// (1) uint8 : type
|
|
|
|
// (4) sint32 : function id
|
|
|
|
// (8) uint64 : tsc
|
|
|
|
// (4) uint32 : thread id
|
2018-07-13 13:38:22 +08:00
|
|
|
// (4) uint32 : process id
|
|
|
|
// (8) - : padding
|
2018-08-07 12:42:39 +08:00
|
|
|
while (Reader.isValidOffset(OffsetPtr)) {
|
|
|
|
if (!Reader.isValidOffsetForDataOfSize(OffsetPtr, 32))
|
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Not enough bytes to read a full record at offset %d.", OffsetPtr);
|
|
|
|
auto PreReadOffset = OffsetPtr;
|
|
|
|
auto RecordType = Reader.getU16(&OffsetPtr);
|
|
|
|
if (OffsetPtr == PreReadOffset)
|
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Failed reading record type at offset %d.", OffsetPtr);
|
|
|
|
|
|
|
|
switch (RecordType) {
|
2017-10-05 13:18:17 +08:00
|
|
|
case 0: { // Normal records.
|
|
|
|
Records.emplace_back();
|
|
|
|
auto &Record = Records.back();
|
|
|
|
Record.RecordType = RecordType;
|
2018-08-07 12:42:39 +08:00
|
|
|
|
|
|
|
PreReadOffset = OffsetPtr;
|
|
|
|
Record.CPU = Reader.getU8(&OffsetPtr);
|
|
|
|
if (OffsetPtr == PreReadOffset)
|
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Failed reading CPU field at offset %d.", OffsetPtr);
|
|
|
|
|
|
|
|
PreReadOffset = OffsetPtr;
|
|
|
|
auto Type = Reader.getU8(&OffsetPtr);
|
|
|
|
if (OffsetPtr == PreReadOffset)
|
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Failed reading record type field at offset %d.", OffsetPtr);
|
|
|
|
|
2017-10-05 13:18:17 +08:00
|
|
|
switch (Type) {
|
|
|
|
case 0:
|
|
|
|
Record.Type = RecordTypes::ENTER;
|
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
Record.Type = RecordTypes::EXIT;
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
Record.Type = RecordTypes::TAIL_EXIT;
|
|
|
|
break;
|
|
|
|
case 3:
|
|
|
|
Record.Type = RecordTypes::ENTER_ARG;
|
|
|
|
break;
|
|
|
|
default:
|
2018-08-07 12:42:39 +08:00
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Unknown record type '%d' at offset %d.", Type, OffsetPtr);
|
2017-10-05 13:18:17 +08:00
|
|
|
}
|
2018-08-07 12:42:39 +08:00
|
|
|
|
|
|
|
PreReadOffset = OffsetPtr;
|
|
|
|
Record.FuncId = Reader.getSigned(&OffsetPtr, sizeof(int32_t));
|
|
|
|
if (OffsetPtr == PreReadOffset)
|
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Failed reading function id field at offset %d.", OffsetPtr);
|
|
|
|
|
|
|
|
PreReadOffset = OffsetPtr;
|
|
|
|
Record.TSC = Reader.getU64(&OffsetPtr);
|
|
|
|
if (OffsetPtr == PreReadOffset)
|
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Failed reading TSC field at offset %d.", OffsetPtr);
|
|
|
|
|
|
|
|
PreReadOffset = OffsetPtr;
|
|
|
|
Record.TId = Reader.getU32(&OffsetPtr);
|
|
|
|
if (OffsetPtr == PreReadOffset)
|
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Failed reading thread id field at offset %d.", OffsetPtr);
|
|
|
|
|
|
|
|
PreReadOffset = OffsetPtr;
|
|
|
|
Record.PId = Reader.getU32(&OffsetPtr);
|
|
|
|
if (OffsetPtr == PreReadOffset)
|
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Failed reading process id at offset %d.", OffsetPtr);
|
|
|
|
|
2017-01-10 10:38:11 +08:00
|
|
|
break;
|
2017-10-05 13:18:17 +08:00
|
|
|
}
|
|
|
|
case 1: { // Arg payload record.
|
|
|
|
auto &Record = Records.back();
|
2018-08-07 12:42:39 +08:00
|
|
|
|
|
|
|
// We skip the next two bytes of the record, because we don't need the
|
|
|
|
// type and the CPU record for arg payloads.
|
2017-10-05 13:18:17 +08:00
|
|
|
OffsetPtr += 2;
|
2018-08-07 12:42:39 +08:00
|
|
|
PreReadOffset = OffsetPtr;
|
|
|
|
int32_t FuncId = Reader.getSigned(&OffsetPtr, sizeof(int32_t));
|
|
|
|
if (OffsetPtr == PreReadOffset)
|
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Failed reading function id field at offset %d.", OffsetPtr);
|
|
|
|
|
|
|
|
PreReadOffset = OffsetPtr;
|
|
|
|
auto TId = Reader.getU32(&OffsetPtr);
|
|
|
|
if (OffsetPtr == PreReadOffset)
|
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Failed reading thread id field at offset %d.", OffsetPtr);
|
|
|
|
|
|
|
|
PreReadOffset = OffsetPtr;
|
|
|
|
auto PId = Reader.getU32(&OffsetPtr);
|
|
|
|
if (OffsetPtr == PreReadOffset)
|
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Failed reading process id field at offset %d.", OffsetPtr);
|
2018-07-13 13:38:22 +08:00
|
|
|
|
|
|
|
// Make a check for versions above 3 for the Pid field
|
|
|
|
if (Record.FuncId != FuncId || Record.TId != TId ||
|
|
|
|
(FileHeader.Version >= 3 ? Record.PId != PId : false))
|
2018-08-07 12:42:39 +08:00
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Corrupted log, found arg payload following non-matching "
|
|
|
|
"function+thread record. Record for function %d != %d at offset "
|
|
|
|
"%d",
|
|
|
|
Record.FuncId, FuncId, OffsetPtr);
|
|
|
|
|
|
|
|
PreReadOffset = OffsetPtr;
|
|
|
|
auto Arg = Reader.getU64(&OffsetPtr);
|
|
|
|
if (OffsetPtr == PreReadOffset)
|
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Failed reading argument payload at offset %d.", OffsetPtr);
|
|
|
|
|
2017-10-05 13:18:17 +08:00
|
|
|
Record.CallArgs.push_back(Arg);
|
2017-09-18 14:08:46 +08:00
|
|
|
break;
|
2017-10-05 13:18:17 +08:00
|
|
|
}
|
2017-01-10 10:38:11 +08:00
|
|
|
default:
|
2018-08-07 12:42:39 +08:00
|
|
|
return createStringError(
|
|
|
|
std::make_error_code(std::errc::executable_format_error),
|
|
|
|
"Unknown record type '%d' at offset %d.", RecordType, OffsetPtr);
|
2017-01-10 10:38:11 +08:00
|
|
|
}
|
2018-08-07 12:42:39 +08:00
|
|
|
// Advance the offset pointer enough bytes to align to 32-byte records for
|
|
|
|
// basic mode logs.
|
|
|
|
OffsetPtr += 8;
|
2017-01-10 10:38:11 +08:00
|
|
|
}
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
2017-02-17 09:47:16 +08:00
|
|
|
/// Reads a log in FDR mode for version 1 of this binary format. FDR mode is
|
|
|
|
/// defined as part of the compiler-rt project in xray_fdr_logging.h, and such
|
|
|
|
/// a log consists of the familiar 32 bit XRayHeader, followed by sequences of
|
|
|
|
/// of interspersed 16 byte Metadata Records and 8 byte Function Records.
|
|
|
|
///
|
|
|
|
/// The following is an attempt to document the grammar of the format, which is
|
|
|
|
/// parsed by this function for little-endian machines. Since the format makes
|
2017-09-15 12:22:16 +08:00
|
|
|
/// use of BitFields, when we support big-endian architectures, we will need to
|
2017-03-30 20:59:53 +08:00
|
|
|
/// adjust not only the endianness parameter to llvm's RecordExtractor, but also
|
2017-02-17 09:47:16 +08:00
|
|
|
/// the bit twiddling logic, which is consistent with the little-endian
|
|
|
|
/// convention that BitFields within a struct will first be packed into the
|
|
|
|
/// least significant bits the address they belong to.
|
|
|
|
///
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
/// We expect a format complying with the grammar in the following pseudo-EBNF
|
|
|
|
/// in Version 1 of the FDR log.
|
2017-02-17 09:47:16 +08:00
|
|
|
///
|
|
|
|
/// FDRLog: XRayFileHeader ThreadBuffer*
|
2017-08-03 05:47:27 +08:00
|
|
|
/// XRayFileHeader: 32 bytes to identify the log as FDR with machine metadata.
|
|
|
|
/// Includes BufferSize
|
|
|
|
/// ThreadBuffer: NewBuffer WallClockTime NewCPUId FunctionSequence EOB
|
2017-03-29 14:10:12 +08:00
|
|
|
/// BufSize: 8 byte unsigned integer indicating how large the buffer is.
|
2017-02-17 09:47:16 +08:00
|
|
|
/// NewBuffer: 16 byte metadata record with Thread Id.
|
|
|
|
/// WallClockTime: 16 byte metadata record with human readable time.
|
2018-07-13 13:38:22 +08:00
|
|
|
/// Pid: 16 byte metadata record with Pid
|
2017-02-17 09:47:16 +08:00
|
|
|
/// NewCPUId: 16 byte metadata record with CPUId and a 64 bit TSC reading.
|
2017-03-29 14:10:12 +08:00
|
|
|
/// EOB: 16 byte record in a thread buffer plus mem garbage to fill BufSize.
|
2017-02-17 09:47:16 +08:00
|
|
|
/// FunctionSequence: NewCPUId | TSCWrap | FunctionRecord
|
|
|
|
/// TSCWrap: 16 byte metadata record with a full 64 bit TSC reading.
|
|
|
|
/// FunctionRecord: 8 byte record with FunctionId, entry/exit, and TSC delta.
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
///
|
|
|
|
/// In Version 2, we make the following changes:
|
|
|
|
///
|
|
|
|
/// ThreadBuffer: BufferExtents NewBuffer WallClockTime NewCPUId
|
|
|
|
/// FunctionSequence
|
|
|
|
/// BufferExtents: 16 byte metdata record describing how many usable bytes are
|
|
|
|
/// in the buffer. This is measured from the start of the buffer
|
|
|
|
/// and must always be at least 48 (bytes).
|
2018-07-13 13:38:22 +08:00
|
|
|
///
|
|
|
|
/// In Version 3, we make the following changes:
|
|
|
|
///
|
|
|
|
/// ThreadBuffer: BufferExtents NewBuffer WallClockTime Pid NewCPUId
|
|
|
|
/// FunctionSequence
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
/// EOB: *deprecated*
|
2018-11-07 12:37:42 +08:00
|
|
|
///
|
|
|
|
/// In Version 4, we make the following changes:
|
|
|
|
///
|
|
|
|
/// CustomEventRecord now includes the CPU data.
|
|
|
|
///
|
|
|
|
/// In Version 5, we make the following changes:
|
|
|
|
///
|
|
|
|
/// CustomEventRecord and TypedEventRecord now use TSC delta encoding similar to
|
|
|
|
/// what FunctionRecord instances use, and we no longer need to include the CPU
|
|
|
|
/// id in the CustomEventRecord.
|
|
|
|
///
|
2018-09-01 01:06:28 +08:00
|
|
|
Error loadFDRLog(StringRef Data, bool IsLittleEndian,
|
|
|
|
XRayFileHeader &FileHeader, std::vector<XRayRecord> &Records) {
|
2018-08-22 15:37:55 +08:00
|
|
|
|
2017-02-17 09:47:16 +08:00
|
|
|
if (Data.size() < 32)
|
2018-09-11 14:45:59 +08:00
|
|
|
return createStringError(std::make_error_code(std::errc::invalid_argument),
|
|
|
|
"Not enough bytes for an XRay FDR log.");
|
|
|
|
DataExtractor DE(Data, IsLittleEndian, 8);
|
2017-02-17 09:47:16 +08:00
|
|
|
|
2018-08-07 12:42:39 +08:00
|
|
|
uint32_t OffsetPtr = 0;
|
2018-09-11 14:45:59 +08:00
|
|
|
auto FileHeaderOrError = readBinaryFormatHeader(DE, OffsetPtr);
|
2018-08-22 15:37:55 +08:00
|
|
|
if (!FileHeaderOrError)
|
|
|
|
return FileHeaderOrError.takeError();
|
|
|
|
FileHeader = std::move(FileHeaderOrError.get());
|
2017-02-17 09:47:16 +08:00
|
|
|
|
2018-09-11 14:45:59 +08:00
|
|
|
// First we load the records into memory.
|
|
|
|
std::vector<std::unique_ptr<Record>> FDRRecords;
|
|
|
|
|
2017-03-29 14:10:12 +08:00
|
|
|
{
|
2018-09-11 14:45:59 +08:00
|
|
|
FileBasedRecordProducer P(FileHeader, DE, OffsetPtr);
|
|
|
|
LogBuilderConsumer C(FDRRecords);
|
|
|
|
while (DE.isValidOffsetForDataOfSize(OffsetPtr, 1)) {
|
|
|
|
auto R = P.produce();
|
|
|
|
if (!R)
|
|
|
|
return R.takeError();
|
|
|
|
if (auto E = C.consume(std::move(R.get())))
|
|
|
|
return E;
|
|
|
|
}
|
2017-03-29 14:10:12 +08:00
|
|
|
}
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
|
2018-09-11 14:45:59 +08:00
|
|
|
// Next we index the records into blocks.
|
|
|
|
BlockIndexer::Index Index;
|
|
|
|
{
|
|
|
|
BlockIndexer Indexer(Index);
|
|
|
|
for (auto &R : FDRRecords)
|
|
|
|
if (auto E = R->apply(Indexer))
|
|
|
|
return E;
|
|
|
|
if (auto E = Indexer.flush())
|
|
|
|
return E;
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
}
|
|
|
|
|
2018-09-11 14:45:59 +08:00
|
|
|
// Then we verify the consistency of the blocks.
|
|
|
|
{
|
|
|
|
for (auto &PTB : Index) {
|
|
|
|
auto &Blocks = PTB.second;
|
|
|
|
for (auto &B : Blocks) {
|
2018-09-13 17:25:42 +08:00
|
|
|
BlockVerifier Verifier;
|
2018-09-11 14:45:59 +08:00
|
|
|
for (auto *R : B.Records)
|
|
|
|
if (auto E = R->apply(Verifier))
|
|
|
|
return E;
|
|
|
|
if (auto E = Verifier.verify())
|
|
|
|
return E;
|
|
|
|
}
|
2017-02-17 09:47:16 +08:00
|
|
|
}
|
2018-09-11 14:45:59 +08:00
|
|
|
}
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
|
2018-09-11 14:45:59 +08:00
|
|
|
// This is now the meat of the algorithm. Here we sort the blocks according to
|
|
|
|
// the Walltime record in each of the blocks for the same thread. This allows
|
|
|
|
// us to more consistently recreate the execution trace in temporal order.
|
|
|
|
// After the sort, we then reconstitute `Trace` records using a stateful
|
|
|
|
// visitor associated with a single process+thread pair.
|
|
|
|
{
|
|
|
|
for (auto &PTB : Index) {
|
|
|
|
auto &Blocks = PTB.second;
|
2018-11-01 08:18:52 +08:00
|
|
|
llvm::sort(Blocks, [](const BlockIndexer::Block &L,
|
|
|
|
const BlockIndexer::Block &R) {
|
|
|
|
return (L.WallclockTime->seconds() < R.WallclockTime->seconds() &&
|
|
|
|
L.WallclockTime->nanos() < R.WallclockTime->nanos());
|
|
|
|
});
|
2018-09-11 16:03:30 +08:00
|
|
|
auto Adder = [&](const XRayRecord &R) { Records.push_back(R); };
|
|
|
|
TraceExpander Expander(Adder, FileHeader.Version);
|
2018-09-11 14:45:59 +08:00
|
|
|
for (auto &B : Blocks) {
|
|
|
|
for (auto *R : B.Records)
|
|
|
|
if (auto E = R->apply(Expander))
|
|
|
|
return E;
|
|
|
|
}
|
|
|
|
if (auto E = Expander.flush())
|
|
|
|
return E;
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
}
|
2017-02-17 09:47:16 +08:00
|
|
|
}
|
2017-09-15 12:22:16 +08:00
|
|
|
|
2017-02-17 09:47:16 +08:00
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error loadYAMLLog(StringRef Data, XRayFileHeader &FileHeader,
|
|
|
|
std::vector<XRayRecord> &Records) {
|
2017-01-10 10:38:11 +08:00
|
|
|
YAMLXRayTrace Trace;
|
|
|
|
Input In(Data);
|
|
|
|
In >> Trace;
|
|
|
|
if (In.error())
|
|
|
|
return make_error<StringError>("Failed loading YAML Data.", In.error());
|
|
|
|
|
|
|
|
FileHeader.Version = Trace.Header.Version;
|
|
|
|
FileHeader.Type = Trace.Header.Type;
|
|
|
|
FileHeader.ConstantTSC = Trace.Header.ConstantTSC;
|
|
|
|
FileHeader.NonstopTSC = Trace.Header.NonstopTSC;
|
|
|
|
FileHeader.CycleFrequency = Trace.Header.CycleFrequency;
|
|
|
|
|
|
|
|
if (FileHeader.Version != 1)
|
|
|
|
return make_error<StringError>(
|
|
|
|
Twine("Unsupported XRay file version: ") + Twine(FileHeader.Version),
|
|
|
|
std::make_error_code(std::errc::invalid_argument));
|
|
|
|
|
|
|
|
Records.clear();
|
|
|
|
std::transform(Trace.Records.begin(), Trace.Records.end(),
|
|
|
|
std::back_inserter(Records), [&](const YAMLXRayRecord &R) {
|
2018-11-06 16:51:37 +08:00
|
|
|
return XRayRecord{R.RecordType, R.CPU, R.Type,
|
|
|
|
R.FuncId, R.TSC, R.TId,
|
|
|
|
R.PId, R.CallArgs, R.Data};
|
2017-01-10 10:38:11 +08:00
|
|
|
});
|
|
|
|
return Error::success();
|
|
|
|
}
|
2017-08-20 21:03:48 +08:00
|
|
|
} // namespace
|
2017-01-11 14:39:09 +08:00
|
|
|
|
|
|
|
Expected<Trace> llvm::xray::loadTraceFile(StringRef Filename, bool Sort) {
|
|
|
|
int Fd;
|
|
|
|
if (auto EC = sys::fs::openFileForRead(Filename, Fd)) {
|
|
|
|
return make_error<StringError>(
|
|
|
|
Twine("Cannot read log from '") + Filename + "'", EC);
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t FileSize;
|
|
|
|
if (auto EC = sys::fs::file_size(Filename, FileSize)) {
|
|
|
|
return make_error<StringError>(
|
|
|
|
Twine("Cannot read log from '") + Filename + "'", EC);
|
|
|
|
}
|
|
|
|
if (FileSize < 4) {
|
|
|
|
return make_error<StringError>(
|
|
|
|
Twine("File '") + Filename + "' too small for XRay.",
|
2017-01-13 02:33:14 +08:00
|
|
|
std::make_error_code(std::errc::executable_format_error));
|
2017-01-11 14:39:09 +08:00
|
|
|
}
|
|
|
|
|
2017-09-15 12:22:16 +08:00
|
|
|
// Map the opened file into memory and use a StringRef to access it later.
|
2017-01-11 14:39:09 +08:00
|
|
|
std::error_code EC;
|
|
|
|
sys::fs::mapped_file_region MappedFile(
|
|
|
|
Fd, sys::fs::mapped_file_region::mapmode::readonly, FileSize, 0, EC);
|
|
|
|
if (EC) {
|
|
|
|
return make_error<StringError>(
|
|
|
|
Twine("Cannot read log from '") + Filename + "'", EC);
|
|
|
|
}
|
2017-09-15 12:22:16 +08:00
|
|
|
auto Data = StringRef(MappedFile.data(), MappedFile.size());
|
2018-09-01 01:06:28 +08:00
|
|
|
|
|
|
|
// TODO: Lift the endianness and implementation selection here.
|
|
|
|
DataExtractor LittleEndianDE(Data, true, 8);
|
|
|
|
auto TraceOrError = loadTrace(LittleEndianDE, Sort);
|
|
|
|
if (!TraceOrError) {
|
|
|
|
DataExtractor BigEndianDE(Data, false, 8);
|
|
|
|
TraceOrError = loadTrace(BigEndianDE, Sort);
|
|
|
|
}
|
|
|
|
return TraceOrError;
|
2018-08-24 18:30:37 +08:00
|
|
|
}
|
2017-01-11 14:39:09 +08:00
|
|
|
|
2018-08-24 18:30:37 +08:00
|
|
|
Expected<Trace> llvm::xray::loadTrace(const DataExtractor &DE, bool Sort) {
|
2017-01-11 14:39:09 +08:00
|
|
|
// Attempt to detect the file type using file magic. We have a slight bias
|
|
|
|
// towards the binary format, and we do this by making sure that the first 4
|
|
|
|
// bytes of the binary file is some combination of the following byte
|
2017-09-15 12:22:16 +08:00
|
|
|
// patterns: (observe the code loading them assumes they're little endian)
|
2017-01-11 14:39:09 +08:00
|
|
|
//
|
2017-09-15 12:22:16 +08:00
|
|
|
// 0x01 0x00 0x00 0x00 - version 1, "naive" format
|
|
|
|
// 0x01 0x00 0x01 0x00 - version 1, "flight data recorder" format
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
// 0x02 0x00 0x01 0x00 - version 2, "flight data recorder" format
|
2017-01-11 14:39:09 +08:00
|
|
|
//
|
2017-09-15 12:22:16 +08:00
|
|
|
// YAML files don't typically have those first four bytes as valid text so we
|
2017-01-11 14:39:09 +08:00
|
|
|
// try loading assuming YAML if we don't find these bytes.
|
|
|
|
//
|
|
|
|
// Only if we can't load either the binary or the YAML format will we yield an
|
|
|
|
// error.
|
2018-09-01 01:06:28 +08:00
|
|
|
DataExtractor HeaderExtractor(DE.getData(), DE.isLittleEndian(), 8);
|
2017-01-11 14:39:09 +08:00
|
|
|
uint32_t OffsetPtr = 0;
|
|
|
|
uint16_t Version = HeaderExtractor.getU16(&OffsetPtr);
|
|
|
|
uint16_t Type = HeaderExtractor.getU16(&OffsetPtr);
|
|
|
|
|
2017-02-17 09:47:16 +08:00
|
|
|
enum BinaryFormatType { NAIVE_FORMAT = 0, FLIGHT_DATA_RECORDER_FORMAT = 1 };
|
|
|
|
|
2017-01-11 14:39:09 +08:00
|
|
|
Trace T;
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
switch (Type) {
|
|
|
|
case NAIVE_FORMAT:
|
2018-07-13 13:38:22 +08:00
|
|
|
if (Version == 1 || Version == 2 || Version == 3) {
|
2018-09-01 01:06:28 +08:00
|
|
|
if (auto E = loadNaiveFormatLog(DE.getData(), DE.isLittleEndian(),
|
|
|
|
T.FileHeader, T.Records))
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
return std::move(E);
|
|
|
|
} else {
|
|
|
|
return make_error<StringError>(
|
|
|
|
Twine("Unsupported version for Basic/Naive Mode logging: ") +
|
|
|
|
Twine(Version),
|
|
|
|
std::make_error_code(std::errc::executable_format_error));
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case FLIGHT_DATA_RECORDER_FORMAT:
|
2018-11-07 12:37:42 +08:00
|
|
|
if (Version >= 1 && Version <= 5) {
|
2018-09-01 01:06:28 +08:00
|
|
|
if (auto E = loadFDRLog(DE.getData(), DE.isLittleEndian(), T.FileHeader,
|
|
|
|
T.Records))
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
return std::move(E);
|
|
|
|
} else {
|
|
|
|
return make_error<StringError>(
|
|
|
|
Twine("Unsupported version for FDR Mode logging: ") + Twine(Version),
|
|
|
|
std::make_error_code(std::errc::executable_format_error));
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
2018-08-24 18:30:37 +08:00
|
|
|
if (auto E = loadYAMLLog(DE.getData(), T.FileHeader, T.Records))
|
2017-01-11 14:39:09 +08:00
|
|
|
return std::move(E);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Sort)
|
2017-11-15 02:11:08 +08:00
|
|
|
std::stable_sort(T.Records.begin(), T.Records.end(),
|
2018-08-07 12:42:39 +08:00
|
|
|
[&](const XRayRecord &L, const XRayRecord &R) {
|
|
|
|
return L.TSC < R.TSC;
|
|
|
|
});
|
2017-01-11 14:39:09 +08:00
|
|
|
|
|
|
|
return std::move(T);
|
|
|
|
}
|