[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
//===-- xray_fdr_logging.cc ------------------------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
[XRay] [compiler-rt] Refactor logic for xray fdr logging. NFC.
Summary:
Separated the IO and the thread local storage state machine of logging
from the writing of log records once the contents are deterministic.
Finer granularity functions are provided as inline functions in the same
header such that stack does not grow due to the functions being separated.
An executable utility xray_fdr_log_printer is also implemented to use the
finest granularity functions to produce binary test data in the FDR format
with a relatively convenient text input.
For example, one can take a file with textual contents layed out in rows
and feed it to the binary to generate data that llvm-xray convert can then
read. This is a convenient way to build a test suite for llvm-xray convert
to ensure it's robust to the fdr format.
Example:
$cat myFile.txt
NewBuffer : { time = 2 , Tid=5}
NewCPU : { CPU =1 , TSC = 123}
Function : { FuncId = 5, TSCDelta = 3, EntryType = Entry }
Function : { FuncId = 5, TSCDelta = 5, EntryType = Exit}
TSCWrap : { TSC = 678 }
Function : { FuncId = 6, TSCDelta = 0, EntryType = Entry }
Function : { FuncId = 6, TSCDelta = 50, EntryType = Exit }
EOB : { }
$cat myFile.txt | ./bin/xray_fdr_log_printer > /tmp/binarydata.bin
$./bin/llvm-xray convert -output-format=yaml -output=- /tmp/binarydata.bin
yaml format comes out as expected.
Reviewers: dberris, pelikan
Reviewed By: dberris
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30850
llvm-svn: 297801
2017-03-15 11:12:01 +08:00
|
|
|
// This file is a part of XRay, a dynamic runtime instrumentation system.
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
//
|
|
|
|
// Here we implement the Flight Data Recorder mode for XRay, where we use
|
|
|
|
// compact structures to store records in memory as well as when writing out the
|
|
|
|
// data to files.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#include "xray_fdr_logging.h"
|
2018-06-08 16:42:37 +08:00
|
|
|
#include <pthread.h>
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
#include <cassert>
|
[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
|
|
|
#include <errno.h>
|
2018-06-05 16:20:54 +08:00
|
|
|
#include <limits>
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
#include <memory>
|
2017-02-06 09:48:21 +08:00
|
|
|
#include <sys/syscall.h>
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
#include <sys/time.h>
|
|
|
|
#include <time.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
|
2018-06-05 18:12:58 +08:00
|
|
|
#include "sanitizer_common/sanitizer_allocator_internal.h"
|
2017-03-27 15:13:35 +08:00
|
|
|
#include "sanitizer_common/sanitizer_atomic.h"
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
#include "sanitizer_common/sanitizer_common.h"
|
|
|
|
#include "xray/xray_interface.h"
|
|
|
|
#include "xray/xray_records.h"
|
|
|
|
#include "xray_buffer_queue.h"
|
|
|
|
#include "xray_defs.h"
|
2018-05-04 14:13:35 +08:00
|
|
|
#include "xray_fdr_flags.h"
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
#include "xray_flags.h"
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
#include "xray_recursion_guard.h"
|
2017-02-11 04:30:43 +08:00
|
|
|
#include "xray_tsc.h"
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
#include "xray_utils.h"
|
|
|
|
|
|
|
|
namespace __xray {
|
|
|
|
|
2018-06-05 16:20:54 +08:00
|
|
|
atomic_sint32_t LoggingStatus = {XRayLogInitStatus::XRAY_LOG_UNINITIALIZED};
|
|
|
|
|
|
|
|
// Group together thread-local-data in a struct, then hide it behind a function
|
|
|
|
// call so that it can be initialized on first use instead of as a global. We
|
|
|
|
// force the alignment to 64-bytes for x86 cache line alignment, as this
|
|
|
|
// structure is used in the hot path of implementation.
|
|
|
|
struct alignas(64) ThreadLocalData {
|
|
|
|
BufferQueue::Buffer Buffer;
|
|
|
|
char *RecordPtr = nullptr;
|
|
|
|
// The number of FunctionEntry records immediately preceding RecordPtr.
|
|
|
|
uint8_t NumConsecutiveFnEnters = 0;
|
|
|
|
|
|
|
|
// The number of adjacent, consecutive pairs of FunctionEntry, Tail Exit
|
|
|
|
// records preceding RecordPtr.
|
|
|
|
uint8_t NumTailCalls = 0;
|
|
|
|
|
|
|
|
// We use a thread_local variable to keep track of which CPUs we've already
|
|
|
|
// run, and the TSC times for these CPUs. This allows us to stop repeating the
|
|
|
|
// CPU field in the function records.
|
|
|
|
//
|
|
|
|
// We assume that we'll support only 65536 CPUs for x86_64.
|
|
|
|
uint16_t CurrentCPU = std::numeric_limits<uint16_t>::max();
|
|
|
|
uint64_t LastTSC = 0;
|
|
|
|
uint64_t LastFunctionEntryTSC = 0;
|
|
|
|
|
|
|
|
// Make sure a thread that's ever called handleArg0 has a thread-local
|
|
|
|
// live reference to the buffer queue for this particular instance of
|
|
|
|
// FDRLogging, and that we're going to clean it up when the thread exits.
|
|
|
|
BufferQueue *BQ = nullptr;
|
|
|
|
};
|
|
|
|
|
|
|
|
static_assert(std::is_trivially_destructible<ThreadLocalData>::value,
|
|
|
|
"ThreadLocalData must be trivially destructible");
|
|
|
|
|
|
|
|
static constexpr auto MetadataRecSize = sizeof(MetadataRecord);
|
|
|
|
static constexpr auto FunctionRecSize = sizeof(FunctionRecord);
|
|
|
|
|
|
|
|
// Use a global pthread key to identify thread-local data for logging.
|
|
|
|
static pthread_key_t Key;
|
|
|
|
|
|
|
|
// This function will initialize the thread-local data structure used by the FDR
|
|
|
|
// logging implementation and return a reference to it. The implementation
|
|
|
|
// details require a bit of care to maintain.
|
|
|
|
//
|
|
|
|
// First, some requirements on the implementation in general:
|
|
|
|
//
|
|
|
|
// - XRay handlers should not call any memory allocation routines that may
|
|
|
|
// delegate to an instrumented implementation. This means functions like
|
|
|
|
// malloc() and free() should not be called while instrumenting.
|
|
|
|
//
|
|
|
|
// - We would like to use some thread-local data initialized on first-use of
|
|
|
|
// the XRay instrumentation. These allow us to implement unsynchronized
|
|
|
|
// routines that access resources associated with the thread.
|
|
|
|
//
|
|
|
|
// The implementation here uses a few mechanisms that allow us to provide both
|
|
|
|
// the requirements listed above. We do this by:
|
|
|
|
//
|
|
|
|
// 1. Using a thread-local aligned storage buffer for representing the
|
|
|
|
// ThreadLocalData struct. This data will be uninitialized memory by
|
|
|
|
// design.
|
|
|
|
//
|
|
|
|
// 2. Not requiring a thread exit handler/implementation, keeping the
|
|
|
|
// thread-local as purely a collection of references/data that do not
|
|
|
|
// require cleanup.
|
|
|
|
//
|
|
|
|
// We're doing this to avoid using a `thread_local` object that has a
|
|
|
|
// non-trivial destructor, because the C++ runtime might call std::malloc(...)
|
|
|
|
// to register calls to destructors. Deadlocks may arise when, for example, an
|
|
|
|
// externally provided malloc implementation is XRay instrumented, and
|
|
|
|
// initializing the thread-locals involves calling into malloc. A malloc
|
|
|
|
// implementation that does global synchronization might be holding a lock for a
|
|
|
|
// critical section, calling a function that might be XRay instrumented (and
|
|
|
|
// thus in turn calling into malloc by virtue of registration of the
|
|
|
|
// thread_local's destructor).
|
|
|
|
static ThreadLocalData &getThreadLocalData() {
|
|
|
|
static_assert(alignof(ThreadLocalData) >= 64,
|
|
|
|
"ThreadLocalData must be cache line aligned.");
|
|
|
|
thread_local ThreadLocalData TLD;
|
|
|
|
thread_local bool UNUSED ThreadOnce = [] {
|
|
|
|
pthread_setspecific(Key, &TLD);
|
|
|
|
return false;
|
|
|
|
}();
|
|
|
|
return TLD;
|
|
|
|
}
|
|
|
|
|
2018-07-13 13:38:22 +08:00
|
|
|
static void writeNewBufferPreamble(tid_t Tid, timespec TS,
|
|
|
|
pid_t Pid) XRAY_NEVER_INSTRUMENT {
|
|
|
|
static constexpr int InitRecordsCount = 3;
|
2018-06-05 16:20:54 +08:00
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
MetadataRecord Metadata[InitRecordsCount];
|
|
|
|
{
|
|
|
|
// 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)
|
|
|
|
auto &NewBuffer = Metadata[0];
|
|
|
|
NewBuffer.Type = uint8_t(RecordType::Metadata);
|
|
|
|
NewBuffer.RecordKind = uint8_t(MetadataRecord::RecordKinds::NewBuffer);
|
|
|
|
int32_t tid = static_cast<int32_t>(Tid);
|
|
|
|
internal_memcpy(&NewBuffer.Data, &tid, sizeof(tid));
|
|
|
|
}
|
|
|
|
|
|
|
|
// Also write the WalltimeMarker record.
|
|
|
|
{
|
|
|
|
static_assert(sizeof(time_t) <= 8, "time_t needs to be at most 8 bytes");
|
|
|
|
auto &WalltimeMarker = Metadata[1];
|
|
|
|
WalltimeMarker.Type = uint8_t(RecordType::Metadata);
|
|
|
|
WalltimeMarker.RecordKind =
|
|
|
|
uint8_t(MetadataRecord::RecordKinds::WalltimeMarker);
|
|
|
|
|
|
|
|
// 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.
|
|
|
|
int32_t Micros = TS.tv_nsec / 1000;
|
|
|
|
int64_t Seconds = TS.tv_sec;
|
|
|
|
internal_memcpy(WalltimeMarker.Data, &Seconds, sizeof(Seconds));
|
|
|
|
internal_memcpy(WalltimeMarker.Data + sizeof(Seconds), &Micros,
|
|
|
|
sizeof(Micros));
|
|
|
|
}
|
|
|
|
|
2018-07-13 13:38:22 +08:00
|
|
|
// Also write the Pid record.
|
|
|
|
{
|
|
|
|
// Write out a MetadataRecord that contains the current pid
|
|
|
|
auto &PidMetadata = Metadata[2];
|
|
|
|
PidMetadata.Type = uint8_t(RecordType::Metadata);
|
|
|
|
PidMetadata.RecordKind = uint8_t(MetadataRecord::RecordKinds::Pid);
|
|
|
|
int32_t pid = static_cast<int32_t>(Pid);
|
|
|
|
internal_memcpy(&PidMetadata.Data, &pid, sizeof(pid));
|
|
|
|
}
|
|
|
|
|
2018-06-05 16:20:54 +08:00
|
|
|
TLD.NumConsecutiveFnEnters = 0;
|
|
|
|
TLD.NumTailCalls = 0;
|
|
|
|
if (TLD.BQ == nullptr || TLD.BQ->finalizing())
|
|
|
|
return;
|
|
|
|
internal_memcpy(TLD.RecordPtr, Metadata, sizeof(Metadata));
|
|
|
|
TLD.RecordPtr += sizeof(Metadata);
|
|
|
|
// Since we write out the extents as the first metadata record of the
|
|
|
|
// buffer, we need to write out the extents including the extents record.
|
|
|
|
atomic_store(&TLD.Buffer.Extents->Size, sizeof(Metadata),
|
|
|
|
memory_order_release);
|
|
|
|
}
|
|
|
|
|
2018-06-05 18:18:39 +08:00
|
|
|
static void setupNewBuffer(int (*wall_clock_reader)(
|
2018-06-05 16:20:54 +08:00
|
|
|
clockid_t, struct timespec *)) XRAY_NEVER_INSTRUMENT {
|
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
auto &B = TLD.Buffer;
|
|
|
|
TLD.RecordPtr = static_cast<char *>(B.Data);
|
|
|
|
tid_t Tid = GetTid();
|
|
|
|
timespec TS{0, 0};
|
2018-07-13 13:38:22 +08:00
|
|
|
pid_t Pid = internal_getpid();
|
2018-06-05 16:20:54 +08:00
|
|
|
// This is typically clock_gettime, but callers have injection ability.
|
|
|
|
wall_clock_reader(CLOCK_MONOTONIC, &TS);
|
2018-07-13 13:38:22 +08:00
|
|
|
writeNewBufferPreamble(Tid, TS, Pid);
|
2018-06-05 16:20:54 +08:00
|
|
|
TLD.NumConsecutiveFnEnters = 0;
|
|
|
|
TLD.NumTailCalls = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void incrementExtents(size_t Add) {
|
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
atomic_fetch_add(&TLD.Buffer.Extents->Size, Add, memory_order_acq_rel);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void decrementExtents(size_t Subtract) {
|
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
atomic_fetch_sub(&TLD.Buffer.Extents->Size, Subtract, memory_order_acq_rel);
|
|
|
|
}
|
|
|
|
|
2018-06-05 18:18:39 +08:00
|
|
|
static void writeNewCPUIdMetadata(uint16_t CPU,
|
2018-06-05 16:20:54 +08:00
|
|
|
uint64_t TSC) XRAY_NEVER_INSTRUMENT {
|
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
MetadataRecord NewCPUId;
|
|
|
|
NewCPUId.Type = uint8_t(RecordType::Metadata);
|
|
|
|
NewCPUId.RecordKind = uint8_t(MetadataRecord::RecordKinds::NewCPUId);
|
|
|
|
|
|
|
|
// The data for the New CPU will contain the following bytes:
|
|
|
|
// - CPU ID (uint16_t, 2 bytes)
|
|
|
|
// - Full TSC (uint64_t, 8 bytes)
|
|
|
|
// Total = 10 bytes.
|
|
|
|
internal_memcpy(&NewCPUId.Data, &CPU, sizeof(CPU));
|
|
|
|
internal_memcpy(&NewCPUId.Data[sizeof(CPU)], &TSC, sizeof(TSC));
|
|
|
|
internal_memcpy(TLD.RecordPtr, &NewCPUId, sizeof(MetadataRecord));
|
|
|
|
TLD.RecordPtr += sizeof(MetadataRecord);
|
|
|
|
TLD.NumConsecutiveFnEnters = 0;
|
|
|
|
TLD.NumTailCalls = 0;
|
|
|
|
incrementExtents(sizeof(MetadataRecord));
|
|
|
|
}
|
|
|
|
|
2018-06-05 18:18:39 +08:00
|
|
|
static void writeTSCWrapMetadata(uint64_t TSC) XRAY_NEVER_INSTRUMENT {
|
2018-06-05 16:20:54 +08:00
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
MetadataRecord TSCWrap;
|
|
|
|
TSCWrap.Type = uint8_t(RecordType::Metadata);
|
|
|
|
TSCWrap.RecordKind = uint8_t(MetadataRecord::RecordKinds::TSCWrap);
|
|
|
|
|
|
|
|
// The data for the TSCWrap record contains the following bytes:
|
|
|
|
// - Full TSC (uint64_t, 8 bytes)
|
|
|
|
// Total = 8 bytes.
|
|
|
|
internal_memcpy(&TSCWrap.Data, &TSC, sizeof(TSC));
|
|
|
|
internal_memcpy(TLD.RecordPtr, &TSCWrap, sizeof(MetadataRecord));
|
|
|
|
TLD.RecordPtr += sizeof(MetadataRecord);
|
|
|
|
TLD.NumConsecutiveFnEnters = 0;
|
|
|
|
TLD.NumTailCalls = 0;
|
|
|
|
incrementExtents(sizeof(MetadataRecord));
|
|
|
|
}
|
|
|
|
|
|
|
|
// Call Argument metadata records store the arguments to a function in the
|
|
|
|
// order of their appearance; holes are not supported by the buffer format.
|
2018-06-05 18:18:39 +08:00
|
|
|
static void writeCallArgumentMetadata(uint64_t A) XRAY_NEVER_INSTRUMENT {
|
2018-06-05 16:20:54 +08:00
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
MetadataRecord CallArg;
|
|
|
|
CallArg.Type = uint8_t(RecordType::Metadata);
|
|
|
|
CallArg.RecordKind = uint8_t(MetadataRecord::RecordKinds::CallArgument);
|
|
|
|
|
|
|
|
internal_memcpy(CallArg.Data, &A, sizeof(A));
|
|
|
|
internal_memcpy(TLD.RecordPtr, &CallArg, sizeof(MetadataRecord));
|
|
|
|
TLD.RecordPtr += sizeof(MetadataRecord);
|
|
|
|
incrementExtents(sizeof(MetadataRecord));
|
|
|
|
}
|
|
|
|
|
2018-06-05 18:18:39 +08:00
|
|
|
static void writeFunctionRecord(int FuncId, uint32_t TSCDelta,
|
|
|
|
XRayEntryType EntryType) XRAY_NEVER_INSTRUMENT {
|
2018-06-05 16:20:54 +08:00
|
|
|
FunctionRecord FuncRecord;
|
|
|
|
FuncRecord.Type = uint8_t(RecordType::Function);
|
|
|
|
// Only take 28 bits of the function id.
|
|
|
|
FuncRecord.FuncId = FuncId & ~(0x0F << 28);
|
|
|
|
FuncRecord.TSCDelta = TSCDelta;
|
|
|
|
|
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
switch (EntryType) {
|
|
|
|
case XRayEntryType::ENTRY:
|
|
|
|
++TLD.NumConsecutiveFnEnters;
|
|
|
|
FuncRecord.RecordKind = uint8_t(FunctionRecord::RecordKinds::FunctionEnter);
|
|
|
|
break;
|
|
|
|
case XRayEntryType::LOG_ARGS_ENTRY:
|
|
|
|
// We should not rewind functions with logged args.
|
|
|
|
TLD.NumConsecutiveFnEnters = 0;
|
|
|
|
TLD.NumTailCalls = 0;
|
|
|
|
FuncRecord.RecordKind = uint8_t(FunctionRecord::RecordKinds::FunctionEnter);
|
|
|
|
break;
|
|
|
|
case XRayEntryType::EXIT:
|
|
|
|
// If we've decided to log the function exit, we will never erase the log
|
|
|
|
// before it.
|
|
|
|
TLD.NumConsecutiveFnEnters = 0;
|
|
|
|
TLD.NumTailCalls = 0;
|
|
|
|
FuncRecord.RecordKind = uint8_t(FunctionRecord::RecordKinds::FunctionExit);
|
|
|
|
break;
|
|
|
|
case XRayEntryType::TAIL:
|
|
|
|
// If we just entered the function we're tail exiting from or erased every
|
|
|
|
// invocation since then, this function entry tail pair is a candidate to
|
|
|
|
// be erased when the child function exits.
|
|
|
|
if (TLD.NumConsecutiveFnEnters > 0) {
|
|
|
|
++TLD.NumTailCalls;
|
|
|
|
TLD.NumConsecutiveFnEnters = 0;
|
|
|
|
} else {
|
|
|
|
// We will never be able to erase this tail call since we have logged
|
|
|
|
// something in between the function entry and tail exit.
|
|
|
|
TLD.NumTailCalls = 0;
|
|
|
|
TLD.NumConsecutiveFnEnters = 0;
|
|
|
|
}
|
|
|
|
FuncRecord.RecordKind =
|
|
|
|
uint8_t(FunctionRecord::RecordKinds::FunctionTailExit);
|
|
|
|
break;
|
|
|
|
case XRayEntryType::CUSTOM_EVENT: {
|
|
|
|
// This is a bug in patching, so we'll report it once and move on.
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static atomic_uint8_t ErrorLatch{0};
|
|
|
|
if (!atomic_exchange(&ErrorLatch, 1, memory_order_acq_rel))
|
2018-06-05 16:20:54 +08:00
|
|
|
Report("Internal error: patched an XRay custom event call as a function; "
|
|
|
|
"func id = %d\n",
|
|
|
|
FuncId);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
case XRayEntryType::TYPED_EVENT: {
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static atomic_uint8_t ErrorLatch{0};
|
|
|
|
if (!atomic_exchange(&ErrorLatch, 1, memory_order_acq_rel))
|
2018-06-05 16:20:54 +08:00
|
|
|
Report("Internal error: patched an XRay typed event call as a function; "
|
|
|
|
"func id = %d\n",
|
|
|
|
FuncId);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
internal_memcpy(TLD.RecordPtr, &FuncRecord, sizeof(FunctionRecord));
|
|
|
|
TLD.RecordPtr += sizeof(FunctionRecord);
|
|
|
|
incrementExtents(sizeof(FunctionRecord));
|
|
|
|
}
|
|
|
|
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static atomic_uint64_t TicksPerSec{0};
|
|
|
|
static atomic_uint64_t ThresholdTicks{0};
|
2018-06-05 16:20:54 +08:00
|
|
|
|
|
|
|
// Re-point the thread local pointer into this thread's Buffer before the recent
|
|
|
|
// "Function Entry" record and any "Tail Call Exit" records after that.
|
|
|
|
static void rewindRecentCall(uint64_t TSC, uint64_t &LastTSC,
|
|
|
|
uint64_t &LastFunctionEntryTSC, int32_t FuncId) {
|
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
TLD.RecordPtr -= FunctionRecSize;
|
|
|
|
decrementExtents(FunctionRecSize);
|
|
|
|
FunctionRecord FuncRecord;
|
|
|
|
internal_memcpy(&FuncRecord, TLD.RecordPtr, FunctionRecSize);
|
2018-06-05 18:27:20 +08:00
|
|
|
DCHECK(FuncRecord.RecordKind ==
|
2018-06-05 16:20:54 +08:00
|
|
|
uint8_t(FunctionRecord::RecordKinds::FunctionEnter) &&
|
|
|
|
"Expected to find function entry recording when rewinding.");
|
2018-06-05 18:27:20 +08:00
|
|
|
DCHECK(FuncRecord.FuncId == (FuncId & ~(0x0F << 28)) &&
|
2018-06-05 16:20:54 +08:00
|
|
|
"Expected matching function id when rewinding Exit");
|
|
|
|
--TLD.NumConsecutiveFnEnters;
|
|
|
|
LastTSC -= FuncRecord.TSCDelta;
|
|
|
|
|
|
|
|
// We unwound one call. Update the state and return without writing a log.
|
|
|
|
if (TLD.NumConsecutiveFnEnters != 0) {
|
|
|
|
LastFunctionEntryTSC -= FuncRecord.TSCDelta;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise we've rewound the stack of all function entries, we might be
|
|
|
|
// able to rewind further by erasing tail call functions that are being
|
|
|
|
// exited from via this exit.
|
|
|
|
LastFunctionEntryTSC = 0;
|
|
|
|
auto RewindingTSC = LastTSC;
|
|
|
|
auto RewindingRecordPtr = TLD.RecordPtr - FunctionRecSize;
|
|
|
|
while (TLD.NumTailCalls > 0) {
|
|
|
|
// Rewind the TSC back over the TAIL EXIT record.
|
|
|
|
FunctionRecord ExpectedTailExit;
|
|
|
|
internal_memcpy(&ExpectedTailExit, RewindingRecordPtr, FunctionRecSize);
|
|
|
|
|
2018-06-05 18:27:20 +08:00
|
|
|
DCHECK(ExpectedTailExit.RecordKind ==
|
2018-06-05 16:20:54 +08:00
|
|
|
uint8_t(FunctionRecord::RecordKinds::FunctionTailExit) &&
|
|
|
|
"Expected to find tail exit when rewinding.");
|
|
|
|
RewindingRecordPtr -= FunctionRecSize;
|
|
|
|
RewindingTSC -= ExpectedTailExit.TSCDelta;
|
|
|
|
FunctionRecord ExpectedFunctionEntry;
|
|
|
|
internal_memcpy(&ExpectedFunctionEntry, RewindingRecordPtr,
|
|
|
|
FunctionRecSize);
|
2018-06-05 18:27:20 +08:00
|
|
|
DCHECK(ExpectedFunctionEntry.RecordKind ==
|
2018-06-05 16:20:54 +08:00
|
|
|
uint8_t(FunctionRecord::RecordKinds::FunctionEnter) &&
|
|
|
|
"Expected to find function entry when rewinding tail call.");
|
2018-06-05 18:27:20 +08:00
|
|
|
DCHECK(ExpectedFunctionEntry.FuncId == ExpectedTailExit.FuncId &&
|
2018-06-05 16:20:54 +08:00
|
|
|
"Expected funcids to match when rewinding tail call.");
|
|
|
|
|
|
|
|
// This tail call exceeded the threshold duration. It will not be erased.
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
if ((TSC - RewindingTSC) >= atomic_load_relaxed(&ThresholdTicks)) {
|
2018-06-05 16:20:54 +08:00
|
|
|
TLD.NumTailCalls = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// We can erase a tail exit pair that we're exiting through since
|
|
|
|
// its duration is under threshold.
|
|
|
|
--TLD.NumTailCalls;
|
|
|
|
RewindingRecordPtr -= FunctionRecSize;
|
|
|
|
RewindingTSC -= ExpectedFunctionEntry.TSCDelta;
|
|
|
|
TLD.RecordPtr -= 2 * FunctionRecSize;
|
|
|
|
LastTSC = RewindingTSC;
|
|
|
|
decrementExtents(2 * FunctionRecSize);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-06-05 18:18:39 +08:00
|
|
|
static bool releaseThreadLocalBuffer(BufferQueue &BQArg) {
|
2018-06-05 16:20:54 +08:00
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
auto EC = BQArg.releaseBuffer(TLD.Buffer);
|
|
|
|
if (EC != BufferQueue::ErrorCode::Ok) {
|
|
|
|
Report("Failed to release buffer at %p; error=%s\n", TLD.Buffer.Data,
|
|
|
|
BufferQueue::getErrorString(EC));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-06-05 18:18:39 +08:00
|
|
|
static bool prepareBuffer(uint64_t TSC, unsigned char CPU,
|
2018-06-05 16:20:54 +08:00
|
|
|
int (*wall_clock_reader)(clockid_t,
|
|
|
|
struct timespec *),
|
|
|
|
size_t MaxSize) XRAY_NEVER_INSTRUMENT {
|
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
char *BufferStart = static_cast<char *>(TLD.Buffer.Data);
|
|
|
|
if ((TLD.RecordPtr + MaxSize) > (BufferStart + TLD.Buffer.Size)) {
|
|
|
|
if (!releaseThreadLocalBuffer(*TLD.BQ))
|
|
|
|
return false;
|
|
|
|
auto EC = TLD.BQ->getBuffer(TLD.Buffer);
|
|
|
|
if (EC != BufferQueue::ErrorCode::Ok) {
|
|
|
|
Report("Failed to acquire a buffer; error=%s\n",
|
|
|
|
BufferQueue::getErrorString(EC));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
setupNewBuffer(wall_clock_reader);
|
|
|
|
|
|
|
|
// Always write the CPU metadata as the first record in the buffer.
|
|
|
|
writeNewCPUIdMetadata(CPU, TSC);
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-06-05 18:18:39 +08:00
|
|
|
static bool
|
2018-06-05 16:20:54 +08:00
|
|
|
isLogInitializedAndReady(BufferQueue *LBQ, uint64_t TSC, unsigned char CPU,
|
|
|
|
int (*wall_clock_reader)(clockid_t, struct timespec *))
|
|
|
|
XRAY_NEVER_INSTRUMENT {
|
|
|
|
// Bail out right away if logging is not initialized yet.
|
|
|
|
// We should take the opportunity to release the buffer though.
|
|
|
|
auto Status = atomic_load(&LoggingStatus, memory_order_acquire);
|
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
if (Status != XRayLogInitStatus::XRAY_LOG_INITIALIZED) {
|
|
|
|
if (TLD.RecordPtr != nullptr &&
|
|
|
|
(Status == XRayLogInitStatus::XRAY_LOG_FINALIZING ||
|
|
|
|
Status == XRayLogInitStatus::XRAY_LOG_FINALIZED)) {
|
|
|
|
if (!releaseThreadLocalBuffer(*LBQ))
|
|
|
|
return false;
|
|
|
|
TLD.RecordPtr = nullptr;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (atomic_load(&LoggingStatus, memory_order_acquire) !=
|
|
|
|
XRayLogInitStatus::XRAY_LOG_INITIALIZED ||
|
|
|
|
LBQ->finalizing()) {
|
|
|
|
if (!releaseThreadLocalBuffer(*LBQ))
|
|
|
|
return false;
|
|
|
|
TLD.RecordPtr = nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (TLD.Buffer.Data == nullptr) {
|
|
|
|
auto EC = LBQ->getBuffer(TLD.Buffer);
|
|
|
|
if (EC != BufferQueue::ErrorCode::Ok) {
|
|
|
|
auto LS = atomic_load(&LoggingStatus, memory_order_acquire);
|
|
|
|
if (LS != XRayLogInitStatus::XRAY_LOG_FINALIZING &&
|
|
|
|
LS != XRayLogInitStatus::XRAY_LOG_FINALIZED)
|
|
|
|
Report("Failed to acquire a buffer; error=%s\n",
|
|
|
|
BufferQueue::getErrorString(EC));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
setupNewBuffer(wall_clock_reader);
|
|
|
|
|
|
|
|
// Always write the CPU metadata as the first record in the buffer.
|
|
|
|
writeNewCPUIdMetadata(CPU, TSC);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (TLD.CurrentCPU == std::numeric_limits<uint16_t>::max()) {
|
|
|
|
// This means this is the first CPU this thread has ever run on. We set
|
|
|
|
// the current CPU and record this as the first TSC we've seen.
|
|
|
|
TLD.CurrentCPU = CPU;
|
|
|
|
writeNewCPUIdMetadata(CPU, TSC);
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
2018-06-05 18:01:45 +08:00
|
|
|
}
|
2018-06-05 16:20:54 +08:00
|
|
|
|
|
|
|
// Compute the TSC difference between the time of measurement and the previous
|
|
|
|
// event. There are a few interesting situations we need to account for:
|
|
|
|
//
|
|
|
|
// - The thread has migrated to a different CPU. If this is the case, then
|
|
|
|
// we write down the following records:
|
|
|
|
//
|
|
|
|
// 1. A 'NewCPUId' Metadata record.
|
|
|
|
// 2. A FunctionRecord with a 0 for the TSCDelta field.
|
|
|
|
//
|
|
|
|
// - The TSC delta is greater than the 32 bits we can store in a
|
|
|
|
// FunctionRecord. In this case we write down the following records:
|
|
|
|
//
|
|
|
|
// 1. A 'TSCWrap' Metadata record.
|
|
|
|
// 2. A FunctionRecord with a 0 for the TSCDelta field.
|
|
|
|
//
|
|
|
|
// - The TSC delta is representable within the 32 bits we can store in a
|
|
|
|
// FunctionRecord. In this case we write down just a FunctionRecord with
|
|
|
|
// the correct TSC delta.
|
2018-06-05 18:18:39 +08:00
|
|
|
static uint32_t writeCurrentCPUTSC(ThreadLocalData &TLD, uint64_t TSC,
|
2018-06-05 16:20:54 +08:00
|
|
|
uint8_t CPU) {
|
|
|
|
if (CPU != TLD.CurrentCPU) {
|
|
|
|
// We've moved to a new CPU.
|
|
|
|
writeNewCPUIdMetadata(CPU, TSC);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
// If the delta is greater than the range for a uint32_t, then we write out
|
|
|
|
// the TSC wrap metadata entry with the full TSC, and the TSC for the
|
|
|
|
// function record be 0.
|
|
|
|
uint64_t Delta = TSC - TLD.LastTSC;
|
|
|
|
if (Delta <= std::numeric_limits<uint32_t>::max())
|
|
|
|
return Delta;
|
|
|
|
|
|
|
|
writeTSCWrapMetadata(TSC);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-06-05 18:18:39 +08:00
|
|
|
static void endBufferIfFull() XRAY_NEVER_INSTRUMENT {
|
2018-06-05 16:20:54 +08:00
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
auto BufferStart = static_cast<char *>(TLD.Buffer.Data);
|
|
|
|
if ((TLD.RecordPtr + MetadataRecSize) - BufferStart <=
|
|
|
|
ptrdiff_t{MetadataRecSize}) {
|
|
|
|
if (!releaseThreadLocalBuffer(*TLD.BQ))
|
|
|
|
return;
|
|
|
|
TLD.RecordPtr = nullptr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-06-06 14:07:48 +08:00
|
|
|
thread_local atomic_uint8_t Running{0};
|
2018-06-05 16:20:54 +08:00
|
|
|
|
|
|
|
/// Here's where the meat of the processing happens. The writer captures
|
|
|
|
/// function entry, exit and tail exit points with a time and will create
|
|
|
|
/// TSCWrap, NewCPUId and Function records as necessary. The writer might
|
|
|
|
/// walk backward through its buffer and erase trivial functions to avoid
|
|
|
|
/// polluting the log and may use the buffer queue to obtain or release a
|
|
|
|
/// buffer.
|
2018-06-05 18:18:39 +08:00
|
|
|
static void processFunctionHook(int32_t FuncId, XRayEntryType Entry,
|
2018-06-05 16:20:54 +08:00
|
|
|
uint64_t TSC, unsigned char CPU, uint64_t Arg1,
|
|
|
|
int (*wall_clock_reader)(clockid_t,
|
|
|
|
struct timespec *),
|
|
|
|
BufferQueue *BQ) XRAY_NEVER_INSTRUMENT {
|
|
|
|
__asm volatile("# LLVM-MCA-BEGIN processFunctionHook");
|
|
|
|
// Prevent signal handler recursion, so in case we're already in a log writing
|
|
|
|
// mode and the signal handler comes in (and is also instrumented) then we
|
|
|
|
// don't want to be clobbering potentially partial writes already happening in
|
|
|
|
// the thread. We use a simple thread_local latch to only allow one on-going
|
|
|
|
// handleArg0 to happen at any given time.
|
|
|
|
RecursionGuard Guard{Running};
|
|
|
|
if (!Guard) {
|
2018-06-06 14:07:48 +08:00
|
|
|
DCHECK(atomic_load_relaxed(&Running) && "RecursionGuard is buggy!");
|
2018-06-05 16:20:54 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
|
|
|
|
// In case the reference has been cleaned up before, we make sure we
|
|
|
|
// initialize it to the provided BufferQueue.
|
|
|
|
if (TLD.BQ == nullptr)
|
|
|
|
TLD.BQ = BQ;
|
|
|
|
|
|
|
|
if (!isLogInitializedAndReady(TLD.BQ, TSC, CPU, wall_clock_reader))
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Before we go setting up writing new function entries, we need to be really
|
|
|
|
// careful about the pointer math we're doing. This means we need to ensure
|
|
|
|
// that the record we are about to write is going to fit into the buffer,
|
|
|
|
// without overflowing the buffer.
|
|
|
|
//
|
|
|
|
// To do this properly, we use the following assumptions:
|
|
|
|
//
|
|
|
|
// - The least number of bytes we will ever write is 8
|
|
|
|
// (sizeof(FunctionRecord)) only if the delta between the previous entry
|
|
|
|
// and this entry is within 32 bits.
|
|
|
|
// - The most number of bytes we will ever write is 8 + 16 + 16 = 40.
|
|
|
|
// This is computed by:
|
|
|
|
//
|
|
|
|
// MaxSize = sizeof(FunctionRecord) + 2 * sizeof(MetadataRecord)
|
|
|
|
//
|
|
|
|
// These arise in the following cases:
|
|
|
|
//
|
|
|
|
// 1. When the delta between the TSC we get and the previous TSC for the
|
|
|
|
// same CPU is outside of the uint32_t range, we end up having to
|
|
|
|
// write a MetadataRecord to indicate a "tsc wrap" before the actual
|
|
|
|
// FunctionRecord.
|
|
|
|
// 2. When we learn that we've moved CPUs, we need to write a
|
|
|
|
// MetadataRecord to indicate a "cpu change", and thus write out the
|
|
|
|
// current TSC for that CPU before writing out the actual
|
|
|
|
// FunctionRecord.
|
|
|
|
// 3. When we learn about a new CPU ID, we need to write down a "new cpu
|
|
|
|
// id" MetadataRecord before writing out the actual FunctionRecord.
|
|
|
|
// 4. The second MetadataRecord is the optional function call argument.
|
|
|
|
//
|
|
|
|
// So the math we need to do is to determine whether writing 40 bytes past the
|
|
|
|
// current pointer exceeds the buffer's maximum size. If we don't have enough
|
|
|
|
// space to write 40 bytes in the buffer, we need get a new Buffer, set it up
|
|
|
|
// properly before doing any further writing.
|
|
|
|
size_t MaxSize = FunctionRecSize + 2 * MetadataRecSize;
|
|
|
|
if (!prepareBuffer(TSC, CPU, wall_clock_reader, MaxSize)) {
|
|
|
|
TLD.BQ = nullptr;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// By this point, we are now ready to write up to 40 bytes (explained above).
|
2018-06-05 18:27:20 +08:00
|
|
|
DCHECK((TLD.RecordPtr + MaxSize) - static_cast<char *>(TLD.Buffer.Data) >=
|
2018-06-05 16:20:54 +08:00
|
|
|
static_cast<ptrdiff_t>(MetadataRecSize) &&
|
|
|
|
"Misconfigured BufferQueue provided; Buffer size not large enough.");
|
|
|
|
|
|
|
|
auto RecordTSCDelta = writeCurrentCPUTSC(TLD, TSC, CPU);
|
|
|
|
TLD.LastTSC = TSC;
|
|
|
|
TLD.CurrentCPU = CPU;
|
|
|
|
switch (Entry) {
|
|
|
|
case XRayEntryType::ENTRY:
|
|
|
|
case XRayEntryType::LOG_ARGS_ENTRY:
|
|
|
|
// Update the thread local state for the next invocation.
|
|
|
|
TLD.LastFunctionEntryTSC = TSC;
|
|
|
|
break;
|
|
|
|
case XRayEntryType::TAIL:
|
|
|
|
case XRayEntryType::EXIT:
|
|
|
|
// Break out and write the exit record if we can't erase any functions.
|
|
|
|
if (TLD.NumConsecutiveFnEnters == 0 ||
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
(TSC - TLD.LastFunctionEntryTSC) >=
|
|
|
|
atomic_load_relaxed(&ThresholdTicks))
|
2018-06-05 16:20:54 +08:00
|
|
|
break;
|
|
|
|
rewindRecentCall(TSC, TLD.LastTSC, TLD.LastFunctionEntryTSC, FuncId);
|
|
|
|
return; // without writing log.
|
|
|
|
case XRayEntryType::CUSTOM_EVENT: {
|
|
|
|
// This is a bug in patching, so we'll report it once and move on.
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static atomic_uint8_t ErrorLatch{0};
|
|
|
|
if (!atomic_exchange(&ErrorLatch, 1, memory_order_acq_rel))
|
2018-06-05 16:20:54 +08:00
|
|
|
Report("Internal error: patched an XRay custom event call as a function; "
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
"func id = %d\n",
|
2018-06-05 16:20:54 +08:00
|
|
|
FuncId);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
case XRayEntryType::TYPED_EVENT: {
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static atomic_uint8_t ErrorLatch{0};
|
|
|
|
if (!atomic_exchange(&ErrorLatch, 1, memory_order_acq_rel))
|
2018-06-05 16:20:54 +08:00
|
|
|
Report("Internal error: patched an XRay typed event call as a function; "
|
|
|
|
"func id = %d\n",
|
|
|
|
FuncId);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
writeFunctionRecord(FuncId, RecordTSCDelta, Entry);
|
|
|
|
if (Entry == XRayEntryType::LOG_ARGS_ENTRY)
|
|
|
|
writeCallArgumentMetadata(Arg1);
|
|
|
|
|
|
|
|
// If we've exhausted the buffer by this time, we then release the buffer to
|
|
|
|
// make sure that other threads may start using this buffer.
|
|
|
|
endBufferIfFull();
|
|
|
|
__asm volatile("# LLVM-MCA-END");
|
|
|
|
}
|
|
|
|
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
// Global BufferQueue.
|
[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
|
|
|
BufferQueue *BQ = nullptr;
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
2018-06-05 14:12:42 +08:00
|
|
|
atomic_sint32_t LogFlushStatus = {XRayLogFlushStatus::XRAY_LOG_NOT_FLUSHING};
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
2017-05-12 09:07:41 +08:00
|
|
|
FDRLoggingOptions FDROptions;
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
2018-06-05 14:12:42 +08:00
|
|
|
SpinMutex FDROptionsMutex;
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static XRayFileHeader &fdrCommonHeaderInfo() {
|
|
|
|
static std::aligned_storage<sizeof(XRayFileHeader)>::type HStorage;
|
|
|
|
static pthread_once_t OnceInit = PTHREAD_ONCE_INIT;
|
|
|
|
static bool TSCSupported = true;
|
|
|
|
static uint64_t CycleFrequency = NanosecondsPerSecond;
|
|
|
|
pthread_once(&OnceInit, +[] {
|
|
|
|
XRayFileHeader &H = reinterpret_cast<XRayFileHeader &>(HStorage);
|
2018-05-14 11:35:01 +08:00
|
|
|
// Version 2 of the log writes the extents of the buffer, instead of
|
|
|
|
// relying on an end-of-buffer record.
|
2018-07-13 13:38:22 +08:00
|
|
|
// Version 3 includes PID metadata record
|
|
|
|
H.Version = 3;
|
2018-05-14 11:35:01 +08:00
|
|
|
H.Type = FileTypes::FDR_LOG;
|
|
|
|
|
|
|
|
// Test for required CPU features and cache the cycle frequency
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
TSCSupported = probeRequiredCPUFeatures();
|
|
|
|
if (TSCSupported)
|
|
|
|
CycleFrequency = getTSCFrequency();
|
2018-05-14 11:35:01 +08:00
|
|
|
H.CycleFrequency = CycleFrequency;
|
|
|
|
|
|
|
|
// FIXME: Actually check whether we have 'constant_tsc' and
|
|
|
|
// 'nonstop_tsc' before setting the values in the header.
|
|
|
|
H.ConstantTSC = 1;
|
|
|
|
H.NonstopTSC = 1;
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
});
|
|
|
|
return reinterpret_cast<XRayFileHeader &>(HStorage);
|
2018-05-14 11:35:01 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// This is the iterator implementation, which knows how to handle FDR-mode
|
|
|
|
// specific buffers. This is used as an implementation of the iterator function
|
|
|
|
// needed by __xray_set_buffer_iterator(...). It maintains a global state of the
|
|
|
|
// buffer iteration for the currently installed FDR mode buffers. In particular:
|
|
|
|
//
|
|
|
|
// - If the argument represents the initial state of XRayBuffer ({nullptr, 0})
|
|
|
|
// then the iterator returns the header information.
|
|
|
|
// - If the argument represents the header information ({address of header
|
|
|
|
// info, size of the header info}) then it returns the first FDR buffer's
|
|
|
|
// address and extents.
|
|
|
|
// - It will keep returning the next buffer and extents as there are more
|
|
|
|
// buffers to process. When the input represents the last buffer, it will
|
|
|
|
// return the initial state to signal completion ({nullptr, 0}).
|
|
|
|
//
|
|
|
|
// See xray/xray_log_interface.h for more details on the requirements for the
|
|
|
|
// implementations of __xray_set_buffer_iterator(...) and
|
|
|
|
// __xray_log_process_buffers(...).
|
|
|
|
XRayBuffer fdrIterator(const XRayBuffer B) {
|
2018-05-14 12:14:39 +08:00
|
|
|
DCHECK(internal_strcmp(__xray_log_get_current_mode(), "xray-fdr") == 0);
|
2018-05-14 11:35:01 +08:00
|
|
|
DCHECK(BQ->finalizing());
|
|
|
|
|
|
|
|
if (BQ == nullptr || !BQ->finalizing()) {
|
|
|
|
if (Verbosity())
|
|
|
|
Report(
|
|
|
|
"XRay FDR: Failed global buffer queue is null or not finalizing!\n");
|
|
|
|
return {nullptr, 0};
|
|
|
|
}
|
|
|
|
|
|
|
|
// We use a global scratch-pad for the header information, which only gets
|
|
|
|
// initialized the first time this function is called. We'll update one part
|
|
|
|
// of this information with some relevant data (in particular the number of
|
|
|
|
// buffers to expect).
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static std::aligned_storage<sizeof(XRayFileHeader)>::type HeaderStorage;
|
|
|
|
static pthread_once_t HeaderOnce = PTHREAD_ONCE_INIT;
|
|
|
|
pthread_once(&HeaderOnce, +[] {
|
|
|
|
reinterpret_cast<XRayFileHeader &>(HeaderStorage) = fdrCommonHeaderInfo();
|
|
|
|
});
|
|
|
|
|
|
|
|
// We use a convenience alias for code referring to Header from here on out.
|
|
|
|
auto &Header = reinterpret_cast<XRayFileHeader &>(HeaderStorage);
|
2018-05-14 11:35:01 +08:00
|
|
|
if (B.Data == nullptr && B.Size == 0) {
|
|
|
|
Header.FdrData = FdrAdditionalHeaderData{BQ->ConfiguredBufferSize()};
|
|
|
|
return XRayBuffer{static_cast<void *>(&Header), sizeof(Header)};
|
|
|
|
}
|
|
|
|
|
|
|
|
static BufferQueue::const_iterator It{};
|
|
|
|
static BufferQueue::const_iterator End{};
|
|
|
|
if (B.Data == static_cast<void *>(&Header) && B.Size == sizeof(Header)) {
|
|
|
|
// From this point on, we provide raw access to the raw buffer we're getting
|
|
|
|
// from the BufferQueue. We're relying on the iterators from the current
|
|
|
|
// Buffer queue.
|
|
|
|
It = BQ->cbegin();
|
|
|
|
End = BQ->cend();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (It == End)
|
|
|
|
return {nullptr, 0};
|
|
|
|
|
2018-05-14 11:55:12 +08:00
|
|
|
XRayBuffer Result;
|
|
|
|
Result.Data = It->Data;
|
2018-06-05 14:12:42 +08:00
|
|
|
Result.Size = atomic_load(&It->Extents->Size, memory_order_acquire);
|
2018-05-14 11:35:01 +08:00
|
|
|
++It;
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
// Must finalize before flushing.
|
2017-02-08 07:35:34 +08:00
|
|
|
XRayLogFlushStatus fdrLoggingFlush() XRAY_NEVER_INSTRUMENT {
|
2018-06-05 14:12:42 +08:00
|
|
|
if (atomic_load(&LoggingStatus, memory_order_acquire) !=
|
[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
|
|
|
XRayLogInitStatus::XRAY_LOG_FINALIZED) {
|
2018-06-05 14:12:42 +08:00
|
|
|
if (Verbosity())
|
[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
|
|
|
Report("Not flushing log, implementation is not finalized.\n");
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
return XRayLogFlushStatus::XRAY_LOG_NOT_FLUSHING;
|
[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
|
|
|
}
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
2017-03-27 15:13:35 +08:00
|
|
|
s32 Result = XRayLogFlushStatus::XRAY_LOG_NOT_FLUSHING;
|
2018-06-05 14:12:42 +08:00
|
|
|
if (!atomic_compare_exchange_strong(&LogFlushStatus, &Result,
|
|
|
|
XRayLogFlushStatus::XRAY_LOG_FLUSHING,
|
|
|
|
memory_order_release)) {
|
|
|
|
if (Verbosity())
|
[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
|
|
|
Report("Not flushing log, implementation is still finalizing.\n");
|
2017-03-27 15:13:35 +08:00
|
|
|
return static_cast<XRayLogFlushStatus>(Result);
|
[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
|
|
|
}
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +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
|
|
|
if (BQ == nullptr) {
|
2018-06-05 14:12:42 +08:00
|
|
|
if (Verbosity())
|
[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
|
|
|
Report("Cannot flush when global buffer queue is null.\n");
|
|
|
|
return XRayLogFlushStatus::XRAY_LOG_NOT_FLUSHING;
|
|
|
|
}
|
|
|
|
|
2017-11-28 19:49:22 +08:00
|
|
|
// We wait a number of milliseconds to allow threads to see that we've
|
[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
|
|
|
// finalised before attempting to flush the log.
|
2018-06-05 14:12:42 +08:00
|
|
|
SleepForMillis(fdrFlags()->grace_period_ms);
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
2018-05-14 11:35:01 +08:00
|
|
|
// At this point, we're going to uninstall the iterator implementation, before
|
|
|
|
// we decide to do anything further with the global buffer queue.
|
|
|
|
__xray_log_remove_buffer_iterator();
|
|
|
|
|
|
|
|
if (fdrFlags()->no_file_flush) {
|
|
|
|
if (Verbosity())
|
|
|
|
Report("XRay FDR: Not flushing to file, 'no_file_flush=true'.\n");
|
|
|
|
|
|
|
|
// Clean up the buffer queue, and do not bother writing out the files!
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
BQ->~BufferQueue();
|
|
|
|
InternalFree(BQ);
|
2018-05-14 11:35:01 +08:00
|
|
|
BQ = nullptr;
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
|
2018-06-05 14:12:42 +08:00
|
|
|
atomic_store(&LogFlushStatus, XRayLogFlushStatus::XRAY_LOG_FLUSHED,
|
|
|
|
memory_order_release);
|
2018-05-14 11:35:01 +08:00
|
|
|
return XRayLogFlushStatus::XRAY_LOG_FLUSHED;
|
|
|
|
}
|
|
|
|
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
// We write out the file in the following format:
|
|
|
|
//
|
|
|
|
// 1) We write down the XRay file header with version 1, type FDR_LOG.
|
|
|
|
// 2) Then we use the 'apply' member of the BufferQueue that's live, to
|
|
|
|
// ensure that at this point in time we write down the buffers that have
|
|
|
|
// been released (and marked "used") -- we dump the full buffer for now
|
|
|
|
// (fixed-sized) and let the tools reading the buffers deal with the data
|
|
|
|
// afterwards.
|
|
|
|
//
|
2017-05-12 09:07:41 +08:00
|
|
|
int Fd = -1;
|
|
|
|
{
|
2018-05-04 14:13:35 +08:00
|
|
|
// FIXME: Remove this section of the code, when we remove the struct-based
|
|
|
|
// configuration API.
|
2018-06-05 14:12:42 +08:00
|
|
|
SpinMutexLock Guard(&FDROptionsMutex);
|
2017-05-12 09:07:41 +08:00
|
|
|
Fd = FDROptions.Fd;
|
|
|
|
}
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
if (Fd == -1)
|
|
|
|
Fd = getLogFD();
|
|
|
|
if (Fd == -1) {
|
|
|
|
auto Result = XRayLogFlushStatus::XRAY_LOG_NOT_FLUSHING;
|
2018-06-05 14:12:42 +08:00
|
|
|
atomic_store(&LogFlushStatus, Result, memory_order_release);
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2018-05-14 11:35:01 +08:00
|
|
|
XRayFileHeader Header = fdrCommonHeaderInfo();
|
[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
|
|
|
Header.FdrData = FdrAdditionalHeaderData{BQ->ConfiguredBufferSize()};
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
retryingWriteAll(Fd, reinterpret_cast<char *>(&Header),
|
|
|
|
reinterpret_cast<char *>(&Header) + sizeof(Header));
|
2017-03-29 13:56:37 +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
|
|
|
BQ->apply([&](const BufferQueue::Buffer &B) {
|
|
|
|
// Starting at version 2 of the FDR logging implementation, we only write
|
|
|
|
// the records identified by the extents of the buffer. We use the Extents
|
2018-05-14 11:35:01 +08:00
|
|
|
// from the Buffer and write that out as the first record in the buffer. We
|
|
|
|
// still use a Metadata record, but fill in the extents instead for the
|
[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
|
|
|
// data.
|
|
|
|
MetadataRecord ExtentsRecord;
|
2018-06-05 14:12:42 +08:00
|
|
|
auto BufferExtents = atomic_load(&B.Extents->Size, memory_order_acquire);
|
2018-06-05 18:27:20 +08:00
|
|
|
DCHECK(BufferExtents <= B.Size);
|
[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
|
|
|
ExtentsRecord.Type = uint8_t(RecordType::Metadata);
|
|
|
|
ExtentsRecord.RecordKind =
|
|
|
|
uint8_t(MetadataRecord::RecordKinds::BufferExtents);
|
2018-06-05 16:20:54 +08:00
|
|
|
internal_memcpy(ExtentsRecord.Data, &BufferExtents, sizeof(BufferExtents));
|
[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
|
|
|
if (BufferExtents > 0) {
|
|
|
|
retryingWriteAll(Fd, reinterpret_cast<char *>(&ExtentsRecord),
|
|
|
|
reinterpret_cast<char *>(&ExtentsRecord) +
|
|
|
|
sizeof(MetadataRecord));
|
2018-02-10 17:07:34 +08:00
|
|
|
retryingWriteAll(Fd, reinterpret_cast<char *>(B.Data),
|
|
|
|
reinterpret_cast<char *>(B.Data) + BufferExtents);
|
2017-03-29 13:56:37 +08:00
|
|
|
}
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
});
|
2017-10-04 13:12:00 +08:00
|
|
|
|
2018-06-05 14:12:42 +08:00
|
|
|
atomic_store(&LogFlushStatus, XRayLogFlushStatus::XRAY_LOG_FLUSHED,
|
|
|
|
memory_order_release);
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
return XRayLogFlushStatus::XRAY_LOG_FLUSHED;
|
|
|
|
}
|
|
|
|
|
2017-02-08 07:35:34 +08:00
|
|
|
XRayLogInitStatus fdrLoggingFinalize() XRAY_NEVER_INSTRUMENT {
|
2017-03-27 15:13:35 +08:00
|
|
|
s32 CurrentStatus = XRayLogInitStatus::XRAY_LOG_INITIALIZED;
|
2018-06-05 14:12:42 +08:00
|
|
|
if (!atomic_compare_exchange_strong(&LoggingStatus, &CurrentStatus,
|
|
|
|
XRayLogInitStatus::XRAY_LOG_FINALIZING,
|
|
|
|
memory_order_release)) {
|
|
|
|
if (Verbosity())
|
[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
|
|
|
Report("Cannot finalize log, implementation not initialized.\n");
|
2017-03-27 15:13:35 +08:00
|
|
|
return static_cast<XRayLogInitStatus>(CurrentStatus);
|
[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
|
|
|
}
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
|
|
|
// Do special things to make the log finalize itself, and not allow any more
|
|
|
|
// operations to be performed until re-initialized.
|
[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
|
|
|
BQ->finalize();
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
2018-06-05 14:12:42 +08:00
|
|
|
atomic_store(&LoggingStatus, XRayLogInitStatus::XRAY_LOG_FINALIZED,
|
|
|
|
memory_order_release);
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
return XRayLogInitStatus::XRAY_LOG_FINALIZED;
|
|
|
|
}
|
|
|
|
|
2017-10-28 07:59:41 +08:00
|
|
|
struct TSCAndCPU {
|
[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
|
|
|
uint64_t TSC = 0;
|
|
|
|
unsigned char CPU = 0;
|
2017-10-28 07:59:41 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static TSCAndCPU getTimestamp() XRAY_NEVER_INSTRUMENT {
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
// We want to get the TSC as early as possible, so that we can check whether
|
2018-05-14 11:35:01 +08:00
|
|
|
// we've seen this CPU before. We also do it before we load anything else,
|
|
|
|
// to allow for forward progress with the scheduling.
|
2017-10-28 07:59:41 +08:00
|
|
|
TSCAndCPU Result;
|
2017-04-11 15:45:16 +08:00
|
|
|
|
2017-04-18 11:25:11 +08:00
|
|
|
// Test once for required CPU features
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static pthread_once_t OnceProbe = PTHREAD_ONCE_INIT;
|
|
|
|
static bool TSCSupported = true;
|
|
|
|
pthread_once(&OnceProbe, +[] { TSCSupported = probeRequiredCPUFeatures(); });
|
2017-04-18 11:25:11 +08:00
|
|
|
|
2017-05-12 09:07:41 +08:00
|
|
|
if (TSCSupported) {
|
2017-10-28 07:59:41 +08:00
|
|
|
Result.TSC = __xray::readTSC(Result.CPU);
|
2017-04-11 15:45:16 +08:00
|
|
|
} else {
|
|
|
|
// FIXME: This code needs refactoring as it appears in multiple locations
|
|
|
|
timespec TS;
|
|
|
|
int result = clock_gettime(CLOCK_REALTIME, &TS);
|
|
|
|
if (result != 0) {
|
|
|
|
Report("clock_gettime(2) return %d, errno=%d", result, int(errno));
|
|
|
|
TS = {0, 0};
|
|
|
|
}
|
2017-10-28 07:59:41 +08:00
|
|
|
Result.CPU = 0;
|
|
|
|
Result.TSC = TS.tv_sec * __xray::NanosecondsPerSecond + TS.tv_nsec;
|
2017-04-11 15:45:16 +08:00
|
|
|
}
|
2017-10-28 07:59:41 +08:00
|
|
|
return Result;
|
2017-05-12 09:07:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void fdrLoggingHandleArg0(int32_t FuncId,
|
|
|
|
XRayEntryType Entry) XRAY_NEVER_INSTRUMENT {
|
2017-10-28 07:59:41 +08:00
|
|
|
auto TC = getTimestamp();
|
2018-06-05 18:01:45 +08:00
|
|
|
processFunctionHook(FuncId, Entry, TC.TSC, TC.CPU, 0, clock_gettime, BQ);
|
2017-09-28 13:29:59 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void fdrLoggingHandleArg1(int32_t FuncId, XRayEntryType Entry,
|
|
|
|
uint64_t Arg) XRAY_NEVER_INSTRUMENT {
|
2017-10-28 07:59:41 +08:00
|
|
|
auto TC = getTimestamp();
|
2018-06-05 18:01:45 +08:00
|
|
|
processFunctionHook(FuncId, Entry, TC.TSC, TC.CPU, Arg, clock_gettime, BQ);
|
2017-05-12 09:07:41 +08:00
|
|
|
}
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
2017-05-12 09:07:41 +08:00
|
|
|
void fdrLoggingHandleCustomEvent(void *Event,
|
|
|
|
std::size_t EventSize) XRAY_NEVER_INSTRUMENT {
|
2017-10-28 07:59:41 +08:00
|
|
|
auto TC = getTimestamp();
|
|
|
|
auto &TSC = TC.TSC;
|
|
|
|
auto &CPU = TC.CPU;
|
2017-05-12 09:07:41 +08:00
|
|
|
RecursionGuard Guard{Running};
|
[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
|
|
|
if (!Guard)
|
2017-05-12 09:07:41 +08:00
|
|
|
return;
|
|
|
|
if (EventSize > std::numeric_limits<int32_t>::max()) {
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static pthread_once_t Once = PTHREAD_ONCE_INIT;
|
|
|
|
pthread_once(&Once, +[] { Report("Event size too large.\n"); });
|
2017-05-12 09:07:41 +08:00
|
|
|
}
|
|
|
|
int32_t ReducedEventSize = static_cast<int32_t>(EventSize);
|
2017-08-29 20:21:45 +08:00
|
|
|
auto &TLD = getThreadLocalData();
|
[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
|
|
|
if (!isLogInitializedAndReady(TLD.BQ, TSC, CPU, clock_gettime))
|
2017-05-12 09:07:41 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
// Here we need to prepare the log to handle:
|
|
|
|
// - The metadata record we're going to write. (16 bytes)
|
2018-05-14 11:35:01 +08:00
|
|
|
// - The additional data we're going to write. Currently, that's the size
|
|
|
|
// of the event we're going to dump into the log as free-form bytes.
|
2017-10-17 18:33:24 +08:00
|
|
|
if (!prepareBuffer(TSC, CPU, clock_gettime, MetadataRecSize + EventSize)) {
|
[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
|
|
|
TLD.BQ = nullptr;
|
2017-05-12 09:07:41 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Write the custom event metadata record, which consists of the following
|
|
|
|
// information:
|
|
|
|
// - 8 bytes (64-bits) for the full TSC when the event started.
|
|
|
|
// - 4 bytes (32-bits) for the length of the data.
|
|
|
|
MetadataRecord CustomEvent;
|
|
|
|
CustomEvent.Type = uint8_t(RecordType::Metadata);
|
|
|
|
CustomEvent.RecordKind =
|
|
|
|
uint8_t(MetadataRecord::RecordKinds::CustomEventMarker);
|
2017-10-28 07:59:41 +08:00
|
|
|
constexpr auto TSCSize = sizeof(TC.TSC);
|
2018-06-05 16:20:54 +08:00
|
|
|
internal_memcpy(&CustomEvent.Data, &ReducedEventSize, sizeof(int32_t));
|
|
|
|
internal_memcpy(&CustomEvent.Data[sizeof(int32_t)], &TSC, TSCSize);
|
|
|
|
internal_memcpy(TLD.RecordPtr, &CustomEvent, sizeof(CustomEvent));
|
2017-08-29 20:21:45 +08:00
|
|
|
TLD.RecordPtr += sizeof(CustomEvent);
|
2018-06-05 16:20:54 +08:00
|
|
|
internal_memcpy(TLD.RecordPtr, Event, ReducedEventSize);
|
[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
|
|
|
incrementExtents(MetadataRecSize + EventSize);
|
2017-05-12 09:07:41 +08:00
|
|
|
endBufferIfFull();
|
|
|
|
}
|
|
|
|
|
2018-04-18 05:28:53 +08:00
|
|
|
void fdrLoggingHandleTypedEvent(
|
|
|
|
uint16_t EventType, const void *Event,
|
|
|
|
std::size_t EventSize) noexcept XRAY_NEVER_INSTRUMENT {
|
|
|
|
auto TC = getTimestamp();
|
|
|
|
auto &TSC = TC.TSC;
|
|
|
|
auto &CPU = TC.CPU;
|
|
|
|
RecursionGuard Guard{Running};
|
|
|
|
if (!Guard)
|
|
|
|
return;
|
|
|
|
if (EventSize > std::numeric_limits<int32_t>::max()) {
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static pthread_once_t Once = PTHREAD_ONCE_INIT;
|
|
|
|
pthread_once(&Once, +[] { Report("Event size too large.\n"); });
|
2018-04-18 05:28:53 +08:00
|
|
|
}
|
|
|
|
int32_t ReducedEventSize = static_cast<int32_t>(EventSize);
|
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
if (!isLogInitializedAndReady(TLD.BQ, TSC, CPU, clock_gettime))
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Here we need to prepare the log to handle:
|
|
|
|
// - The metadata record we're going to write. (16 bytes)
|
2018-05-14 11:35:01 +08:00
|
|
|
// - The additional data we're going to write. Currently, that's the size
|
|
|
|
// of the event we're going to dump into the log as free-form bytes.
|
2018-04-18 05:28:53 +08:00
|
|
|
if (!prepareBuffer(TSC, CPU, clock_gettime, MetadataRecSize + EventSize)) {
|
|
|
|
TLD.BQ = nullptr;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
// Write the custom event metadata record, which consists of the following
|
|
|
|
// information:
|
|
|
|
// - 8 bytes (64-bits) for the full TSC when the event started.
|
|
|
|
// - 4 bytes (32-bits) for the length of the data.
|
|
|
|
// - 2 bytes (16-bits) for the event type. 3 bytes remain since one of the
|
|
|
|
// bytes has the record type (Metadata Record) and kind (TypedEvent).
|
|
|
|
// We'll log the error if the event type is greater than 2 bytes.
|
|
|
|
// Event types are generated sequentially, so 2^16 is enough.
|
|
|
|
MetadataRecord TypedEvent;
|
|
|
|
TypedEvent.Type = uint8_t(RecordType::Metadata);
|
|
|
|
TypedEvent.RecordKind =
|
|
|
|
uint8_t(MetadataRecord::RecordKinds::TypedEventMarker);
|
|
|
|
constexpr auto TSCSize = sizeof(TC.TSC);
|
2018-06-05 16:20:54 +08:00
|
|
|
internal_memcpy(&TypedEvent.Data, &ReducedEventSize, sizeof(int32_t));
|
|
|
|
internal_memcpy(&TypedEvent.Data[sizeof(int32_t)], &TSC, TSCSize);
|
|
|
|
internal_memcpy(&TypedEvent.Data[sizeof(int32_t) + TSCSize], &EventType,
|
|
|
|
sizeof(EventType));
|
|
|
|
internal_memcpy(TLD.RecordPtr, &TypedEvent, sizeof(TypedEvent));
|
2018-04-18 05:28:53 +08:00
|
|
|
|
|
|
|
TLD.RecordPtr += sizeof(TypedEvent);
|
2018-06-05 16:20:54 +08:00
|
|
|
internal_memcpy(TLD.RecordPtr, Event, ReducedEventSize);
|
2018-04-18 05:28:53 +08:00
|
|
|
incrementExtents(MetadataRecSize + EventSize);
|
|
|
|
endBufferIfFull();
|
|
|
|
}
|
|
|
|
|
2018-05-04 14:13:35 +08:00
|
|
|
XRayLogInitStatus fdrLoggingInit(size_t BufferSize, size_t BufferMax,
|
2017-05-12 09:07:41 +08:00
|
|
|
void *Options,
|
|
|
|
size_t OptionsSize) XRAY_NEVER_INSTRUMENT {
|
2018-05-04 14:13:35 +08:00
|
|
|
if (Options == nullptr)
|
|
|
|
return XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
|
|
|
|
2017-05-12 09:07:41 +08:00
|
|
|
s32 CurrentStatus = XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
2018-06-05 14:12:42 +08:00
|
|
|
if (!atomic_compare_exchange_strong(&LoggingStatus, &CurrentStatus,
|
|
|
|
XRayLogInitStatus::XRAY_LOG_INITIALIZING,
|
|
|
|
memory_order_release)) {
|
|
|
|
if (Verbosity())
|
[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
|
|
|
Report("Cannot initialize already initialized implementation.\n");
|
2017-05-12 09:07:41 +08:00
|
|
|
return static_cast<XRayLogInitStatus>(CurrentStatus);
|
[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-05-12 09:07:41 +08:00
|
|
|
|
2018-05-04 14:13:35 +08:00
|
|
|
// Because of __xray_log_init_mode(...) which guarantees that this will be
|
|
|
|
// called with BufferSize == 0 and BufferMax == 0 we parse the configuration
|
|
|
|
// provided in the Options pointer as a string instead.
|
|
|
|
if (BufferSize == 0 && BufferMax == 0) {
|
2018-06-05 14:12:42 +08:00
|
|
|
if (Verbosity())
|
2018-05-04 14:13:35 +08:00
|
|
|
Report("Initializing FDR mode with options: %s\n",
|
|
|
|
static_cast<const char *>(Options));
|
|
|
|
|
|
|
|
// TODO: Factor out the flags specific to the FDR mode implementation. For
|
|
|
|
// now, use the global/single definition of the flags, since the FDR mode
|
|
|
|
// flags are already defined there.
|
|
|
|
FlagParser FDRParser;
|
|
|
|
FDRFlags FDRFlags;
|
|
|
|
registerXRayFDRFlags(&FDRParser, &FDRFlags);
|
|
|
|
FDRFlags.setDefaults();
|
|
|
|
|
|
|
|
// Override first from the general XRAY_DEFAULT_OPTIONS compiler-provided
|
|
|
|
// options until we migrate everyone to use the XRAY_FDR_OPTIONS
|
|
|
|
// compiler-provided options.
|
|
|
|
FDRParser.ParseString(useCompilerDefinedFlags());
|
|
|
|
FDRParser.ParseString(useCompilerDefinedFDRFlags());
|
|
|
|
auto *EnvOpts = GetEnv("XRAY_FDR_OPTIONS");
|
|
|
|
if (EnvOpts == nullptr)
|
|
|
|
EnvOpts = "";
|
|
|
|
FDRParser.ParseString(EnvOpts);
|
2018-05-14 11:35:01 +08:00
|
|
|
|
|
|
|
// FIXME: Remove this when we fully remove the deprecated flags.
|
|
|
|
if (internal_strlen(EnvOpts) == 0) {
|
|
|
|
FDRFlags.func_duration_threshold_us =
|
|
|
|
flags()->xray_fdr_log_func_duration_threshold_us;
|
|
|
|
FDRFlags.grace_period_ms = flags()->xray_fdr_log_grace_period_ms;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The provided options should always override the compiler-provided and
|
|
|
|
// environment-variable defined options.
|
2018-05-04 14:13:35 +08:00
|
|
|
FDRParser.ParseString(static_cast<const char *>(Options));
|
|
|
|
*fdrFlags() = FDRFlags;
|
|
|
|
BufferSize = FDRFlags.buffer_size;
|
|
|
|
BufferMax = FDRFlags.buffer_max;
|
2018-06-05 14:12:42 +08:00
|
|
|
SpinMutexLock Guard(&FDROptionsMutex);
|
2018-05-14 11:35:01 +08:00
|
|
|
FDROptions.Fd = -1;
|
|
|
|
FDROptions.ReportErrors = true;
|
2018-05-04 14:13:35 +08:00
|
|
|
} else if (OptionsSize != sizeof(FDRLoggingOptions)) {
|
|
|
|
// FIXME: This is deprecated, and should really be removed.
|
|
|
|
// At this point we use the flag parser specific to the FDR mode
|
|
|
|
// implementation.
|
2018-06-05 14:12:42 +08:00
|
|
|
if (Verbosity())
|
2018-05-04 14:13:35 +08:00
|
|
|
Report("Cannot initialize FDR logging; wrong size for options: %d\n",
|
|
|
|
OptionsSize);
|
2018-06-05 14:12:42 +08:00
|
|
|
return static_cast<XRayLogInitStatus>(
|
|
|
|
atomic_load(&LoggingStatus, memory_order_acquire));
|
2018-05-04 14:13:35 +08:00
|
|
|
} else {
|
2018-06-05 14:12:42 +08:00
|
|
|
if (Verbosity())
|
2018-05-04 14:13:35 +08:00
|
|
|
Report("XRay FDR: struct-based init is deprecated, please use "
|
|
|
|
"string-based configuration instead.\n");
|
2018-06-05 14:12:42 +08:00
|
|
|
SpinMutexLock Guard(&FDROptionsMutex);
|
2018-06-05 16:20:54 +08:00
|
|
|
internal_memcpy(&FDROptions, Options, OptionsSize);
|
2017-05-12 09:07:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool Success = false;
|
[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
|
|
|
|
|
|
|
if (BQ != nullptr) {
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
BQ->~BufferQueue();
|
|
|
|
InternalFree(BQ);
|
[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
|
|
|
BQ = nullptr;
|
|
|
|
}
|
|
|
|
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
if (BQ == nullptr) {
|
|
|
|
BQ = reinterpret_cast<BufferQueue *>(
|
|
|
|
InternalAlloc(sizeof(BufferQueue), nullptr, 64));
|
|
|
|
new (BQ) BufferQueue(BufferSize, BufferMax, Success);
|
|
|
|
}
|
2017-08-02 12:51:40 +08:00
|
|
|
|
2017-05-12 09:07:41 +08:00
|
|
|
if (!Success) {
|
|
|
|
Report("BufferQueue init failed.\n");
|
[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
|
|
|
if (BQ != nullptr) {
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
BQ->~BufferQueue();
|
|
|
|
InternalFree(BQ);
|
[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
|
|
|
BQ = nullptr;
|
|
|
|
}
|
2017-05-12 09:07:41 +08:00
|
|
|
return XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
|
|
|
}
|
|
|
|
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static pthread_once_t OnceInit = PTHREAD_ONCE_INIT;
|
|
|
|
pthread_once(&OnceInit, +[] {
|
|
|
|
atomic_store(&TicksPerSec,
|
|
|
|
probeRequiredCPUFeatures() ? getTSCFrequency()
|
|
|
|
: __xray::NanosecondsPerSecond,
|
|
|
|
memory_order_release);
|
2018-06-05 18:01:45 +08:00
|
|
|
pthread_key_create(&Key, +[](void *) {
|
|
|
|
auto &TLD = getThreadLocalData();
|
[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
|
|
|
if (TLD.BQ == nullptr)
|
|
|
|
return;
|
|
|
|
auto EC = TLD.BQ->releaseBuffer(TLD.Buffer);
|
|
|
|
if (EC != BufferQueue::ErrorCode::Ok)
|
|
|
|
Report("At thread exit, failed to release buffer at %p; error=%s\n",
|
2018-02-10 17:07:34 +08:00
|
|
|
TLD.Buffer.Data, BufferQueue::getErrorString(EC));
|
[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
|
|
|
});
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +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
|
|
|
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
atomic_store(&ThresholdTicks,
|
|
|
|
atomic_load_relaxed(&TicksPerSec) *
|
|
|
|
fdrFlags()->func_duration_threshold_us / 1000000,
|
|
|
|
memory_order_release);
|
2017-09-28 13:29:59 +08:00
|
|
|
// Arg1 handler should go in first to avoid concurrent code accidentally
|
|
|
|
// falling back to arg0 when it should have ran arg1.
|
|
|
|
__xray_set_handler_arg1(fdrLoggingHandleArg1);
|
2017-05-12 09:07:41 +08:00
|
|
|
// Install the actual handleArg0 handler after initialising the buffers.
|
|
|
|
__xray_set_handler(fdrLoggingHandleArg0);
|
|
|
|
__xray_set_customevent_handler(fdrLoggingHandleCustomEvent);
|
2018-04-18 05:28:53 +08:00
|
|
|
__xray_set_typedevent_handler(fdrLoggingHandleTypedEvent);
|
2017-05-12 09:07:41 +08:00
|
|
|
|
2018-05-14 11:35:01 +08:00
|
|
|
// Install the buffer iterator implementation.
|
|
|
|
__xray_log_set_buffer_iterator(fdrIterator);
|
|
|
|
|
2018-06-05 14:12:42 +08:00
|
|
|
atomic_store(&LoggingStatus, XRayLogInitStatus::XRAY_LOG_INITIALIZED,
|
|
|
|
memory_order_release);
|
[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-06-05 14:12:42 +08:00
|
|
|
if (Verbosity())
|
[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
|
|
|
Report("XRay FDR init successful.\n");
|
2017-05-12 09:07:41 +08:00
|
|
|
return XRayLogInitStatus::XRAY_LOG_INITIALIZED;
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
}
|
|
|
|
|
2017-12-05 20:08:56 +08:00
|
|
|
bool fdrLogDynamicInitializer() XRAY_NEVER_INSTRUMENT {
|
|
|
|
XRayLogImpl Impl{
|
|
|
|
fdrLoggingInit,
|
|
|
|
fdrLoggingFinalize,
|
|
|
|
fdrLoggingHandleArg0,
|
|
|
|
fdrLoggingFlush,
|
|
|
|
};
|
|
|
|
auto RegistrationResult = __xray_log_register_mode("xray-fdr", Impl);
|
|
|
|
if (RegistrationResult != XRayLogRegisterStatus::XRAY_REGISTRATION_OK &&
|
2018-06-05 14:12:42 +08:00
|
|
|
Verbosity())
|
2017-12-05 20:08:56 +08:00
|
|
|
Report("Cannot register XRay FDR mode to 'xray-fdr'; error = %d\n",
|
|
|
|
RegistrationResult);
|
2018-06-05 14:12:42 +08:00
|
|
|
if (flags()->xray_fdr_log || !internal_strcmp(flags()->xray_mode, "xray-fdr"))
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
__xray_set_log_impl(Impl);
|
|
|
|
return true;
|
2017-12-05 20:08:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace __xray
|
|
|
|
|
|
|
|
static auto UNUSED Unused = __xray::fdrLogDynamicInitializer();
|