[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_log_interface.cc ---------------------------------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file is a part of XRay, a function call tracing system.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#include "xray/xray_log_interface.h"
|
|
|
|
|
2017-12-05 20:08:56 +08:00
|
|
|
#include "sanitizer_common/sanitizer_allocator_internal.h"
|
2017-03-27 15:13:35 +08:00
|
|
|
#include "sanitizer_common/sanitizer_atomic.h"
|
|
|
|
#include "sanitizer_common/sanitizer_mutex.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/xray_interface.h"
|
|
|
|
#include "xray_defs.h"
|
|
|
|
|
2018-03-07 10:45:14 +08:00
|
|
|
namespace __xray {
|
|
|
|
static __sanitizer::SpinMutex XRayImplMutex;
|
|
|
|
static XRayLogImpl CurrentXRayImpl{nullptr, nullptr, nullptr, nullptr};
|
|
|
|
static XRayLogImpl *GlobalXRayImpl = nullptr;
|
|
|
|
|
|
|
|
// This is the default implementation of a buffer iterator, which always yields
|
|
|
|
// a null buffer.
|
|
|
|
XRayBuffer NullBufferIterator(XRayBuffer) XRAY_NEVER_INSTRUMENT {
|
|
|
|
return {nullptr, 0};
|
|
|
|
}
|
|
|
|
|
|
|
|
// This is the global function responsible for iterating through given buffers.
|
|
|
|
__sanitizer::atomic_uintptr_t XRayBufferIterator{
|
|
|
|
reinterpret_cast<uintptr_t>(&NullBufferIterator)};
|
[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
|
|
|
// We use a linked list of Mode to XRayLogImpl mappings. This is a linked list
|
|
|
|
// when it should be a map because we're avoiding having to depend on C++
|
|
|
|
// standard library data structures at this level of the implementation.
|
|
|
|
struct ModeImpl {
|
|
|
|
ModeImpl *Next;
|
|
|
|
const char *Mode;
|
|
|
|
XRayLogImpl Impl;
|
|
|
|
};
|
|
|
|
|
2018-03-07 10:45:14 +08:00
|
|
|
static ModeImpl SentinelModeImpl{
|
2017-12-05 20:08:56 +08:00
|
|
|
nullptr, nullptr, {nullptr, nullptr, nullptr, nullptr}};
|
2018-03-07 10:45:14 +08:00
|
|
|
static ModeImpl *ModeImpls = &SentinelModeImpl;
|
|
|
|
static const ModeImpl *CurrentMode = nullptr;
|
|
|
|
|
|
|
|
} // namespace __xray
|
|
|
|
|
|
|
|
using namespace __xray;
|
|
|
|
|
|
|
|
void __xray_log_set_buffer_iterator(XRayBuffer (*Iterator)(XRayBuffer))
|
|
|
|
XRAY_NEVER_INSTRUMENT {
|
|
|
|
__sanitizer::atomic_store(&__xray::XRayBufferIterator,
|
|
|
|
reinterpret_cast<uintptr_t>(Iterator),
|
|
|
|
__sanitizer::memory_order_release);
|
|
|
|
}
|
|
|
|
|
|
|
|
void __xray_log_remove_buffer_iterator() XRAY_NEVER_INSTRUMENT {
|
|
|
|
__xray_log_set_buffer_iterator(&NullBufferIterator);
|
|
|
|
}
|
2017-12-05 20:08:56 +08:00
|
|
|
|
|
|
|
XRayLogRegisterStatus
|
|
|
|
__xray_log_register_mode(const char *Mode,
|
|
|
|
XRayLogImpl Impl) XRAY_NEVER_INSTRUMENT {
|
|
|
|
if (Impl.flush_log == nullptr || Impl.handle_arg0 == nullptr ||
|
|
|
|
Impl.log_finalize == nullptr || Impl.log_init == nullptr)
|
|
|
|
return XRayLogRegisterStatus::XRAY_INCOMPLETE_IMPL;
|
|
|
|
|
|
|
|
__sanitizer::SpinMutexLock Guard(&XRayImplMutex);
|
|
|
|
// First, look for whether the mode already has a registered implementation.
|
|
|
|
for (ModeImpl *it = ModeImpls; it != &SentinelModeImpl; it = it->Next) {
|
|
|
|
if (!__sanitizer::internal_strcmp(Mode, it->Mode))
|
|
|
|
return XRayLogRegisterStatus::XRAY_DUPLICATE_MODE;
|
|
|
|
}
|
|
|
|
auto *NewModeImpl =
|
|
|
|
static_cast<ModeImpl *>(__sanitizer::InternalAlloc(sizeof(ModeImpl)));
|
|
|
|
NewModeImpl->Next = ModeImpls;
|
|
|
|
NewModeImpl->Mode = __sanitizer::internal_strdup(Mode);
|
|
|
|
NewModeImpl->Impl = Impl;
|
|
|
|
ModeImpls = NewModeImpl;
|
|
|
|
return XRayLogRegisterStatus::XRAY_REGISTRATION_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
XRayLogRegisterStatus
|
|
|
|
__xray_log_select_mode(const char *Mode) XRAY_NEVER_INSTRUMENT {
|
|
|
|
__sanitizer::SpinMutexLock Guard(&XRayImplMutex);
|
|
|
|
for (ModeImpl *it = ModeImpls; it != &SentinelModeImpl; it = it->Next) {
|
|
|
|
if (!__sanitizer::internal_strcmp(Mode, it->Mode)) {
|
2018-03-07 10:45:14 +08:00
|
|
|
CurrentMode = it;
|
2017-12-05 20:08:56 +08:00
|
|
|
CurrentXRayImpl = it->Impl;
|
|
|
|
GlobalXRayImpl = &CurrentXRayImpl;
|
|
|
|
__xray_set_handler(it->Impl.handle_arg0);
|
|
|
|
return XRayLogRegisterStatus::XRAY_REGISTRATION_OK;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return XRayLogRegisterStatus::XRAY_MODE_NOT_FOUND;
|
|
|
|
}
|
|
|
|
|
2018-03-07 10:45:14 +08:00
|
|
|
const char *__xray_log_get_current_mode() XRAY_NEVER_INSTRUMENT {
|
|
|
|
__sanitizer::SpinMutexLock Guard(&XRayImplMutex);
|
|
|
|
if (CurrentMode != nullptr)
|
|
|
|
return CurrentMode->Mode;
|
|
|
|
return 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
|
|
|
void __xray_set_log_impl(XRayLogImpl Impl) XRAY_NEVER_INSTRUMENT {
|
|
|
|
if (Impl.log_init == nullptr || Impl.log_finalize == nullptr ||
|
|
|
|
Impl.handle_arg0 == nullptr || Impl.flush_log == nullptr) {
|
2017-03-27 15:13:35 +08:00
|
|
|
__sanitizer::SpinMutexLock Guard(&XRayImplMutex);
|
2017-09-21 18:16:56 +08:00
|
|
|
GlobalXRayImpl = nullptr;
|
2018-03-07 10:45:14 +08:00
|
|
|
CurrentMode = nullptr;
|
2017-05-01 08:52:57 +08:00
|
|
|
__xray_remove_handler();
|
|
|
|
__xray_remove_handler_arg1();
|
[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;
|
|
|
|
}
|
|
|
|
|
2017-03-27 15:13:35 +08:00
|
|
|
__sanitizer::SpinMutexLock Guard(&XRayImplMutex);
|
2017-12-05 20:08:56 +08:00
|
|
|
CurrentXRayImpl = Impl;
|
|
|
|
GlobalXRayImpl = &CurrentXRayImpl;
|
2017-05-01 08:52:57 +08:00
|
|
|
__xray_set_handler(Impl.handle_arg0);
|
|
|
|
}
|
|
|
|
|
|
|
|
void __xray_remove_log_impl() XRAY_NEVER_INSTRUMENT {
|
|
|
|
__sanitizer::SpinMutexLock Guard(&XRayImplMutex);
|
2017-09-21 18:16:56 +08:00
|
|
|
GlobalXRayImpl = nullptr;
|
2017-05-01 08:52:57 +08:00
|
|
|
__xray_remove_handler();
|
|
|
|
__xray_remove_handler_arg1();
|
[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-29 13:19:24 +08:00
|
|
|
XRayLogInitStatus __xray_log_init(size_t BufferSize, size_t MaxBuffers,
|
|
|
|
void *Args,
|
|
|
|
size_t ArgsSize) XRAY_NEVER_INSTRUMENT {
|
2017-03-27 15:13:35 +08:00
|
|
|
__sanitizer::SpinMutexLock Guard(&XRayImplMutex);
|
[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 (!GlobalXRayImpl)
|
|
|
|
return XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
|
|
|
return GlobalXRayImpl->log_init(BufferSize, MaxBuffers, Args, ArgsSize);
|
|
|
|
}
|
|
|
|
|
2018-05-04 14:01:12 +08:00
|
|
|
XRayLogInitStatus __xray_log_init_mode(const char *Mode, const char *Config)
|
|
|
|
XRAY_NEVER_INSTRUMENT {
|
|
|
|
__sanitizer::SpinMutexLock Guard(&XRayImplMutex);
|
|
|
|
if (!GlobalXRayImpl)
|
|
|
|
return XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
|
|
|
|
|
|
|
if (Config == nullptr)
|
|
|
|
return XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
|
|
|
|
|
|
|
// Check first whether the current mode is the same as what we expect.
|
|
|
|
if (CurrentMode == nullptr || internal_strcmp(CurrentMode->Mode, Mode) != 0)
|
|
|
|
return XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
|
|
|
|
|
|
|
// Here we do some work to coerce the pointer we're provided, so that
|
|
|
|
// the implementations that still take void* pointers can handle the
|
|
|
|
// data provided in the Config argument.
|
|
|
|
return GlobalXRayImpl->log_init(
|
|
|
|
0, 0, const_cast<void *>(static_cast<const void *>(Config)), 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
XRayLogInitStatus
|
|
|
|
__xray_log_init_mode_bin(const char *Mode, const char *Config,
|
|
|
|
size_t ConfigSize) XRAY_NEVER_INSTRUMENT {
|
|
|
|
__sanitizer::SpinMutexLock Guard(&XRayImplMutex);
|
|
|
|
if (!GlobalXRayImpl)
|
|
|
|
return XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
|
|
|
|
|
|
|
if (Config == nullptr)
|
|
|
|
return XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
|
|
|
|
|
|
|
// Check first whether the current mode is the same as what we expect.
|
|
|
|
if (CurrentMode == nullptr || internal_strcmp(CurrentMode->Mode, Mode) != 0)
|
|
|
|
return XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
|
|
|
|
|
|
|
// Here we do some work to coerce the pointer we're provided, so that
|
|
|
|
// the implementations that still take void* pointers can handle the
|
|
|
|
// data provided in the Config argument.
|
|
|
|
return GlobalXRayImpl->log_init(
|
|
|
|
0, 0, const_cast<void *>(static_cast<const void *>(Config)), ConfigSize);
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
XRayLogInitStatus __xray_log_finalize() XRAY_NEVER_INSTRUMENT {
|
2017-03-27 15:13:35 +08:00
|
|
|
__sanitizer::SpinMutexLock Guard(&XRayImplMutex);
|
[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 (!GlobalXRayImpl)
|
|
|
|
return XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
|
|
|
return GlobalXRayImpl->log_finalize();
|
|
|
|
}
|
|
|
|
|
|
|
|
XRayLogFlushStatus __xray_log_flushLog() XRAY_NEVER_INSTRUMENT {
|
2017-03-27 15:13:35 +08:00
|
|
|
__sanitizer::SpinMutexLock Guard(&XRayImplMutex);
|
[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 (!GlobalXRayImpl)
|
|
|
|
return XRayLogFlushStatus::XRAY_LOG_NOT_FLUSHING;
|
|
|
|
return GlobalXRayImpl->flush_log();
|
|
|
|
}
|
2018-03-07 10:45:14 +08:00
|
|
|
|
|
|
|
XRayLogFlushStatus __xray_log_process_buffers(
|
|
|
|
void (*Processor)(const char *, XRayBuffer)) XRAY_NEVER_INSTRUMENT {
|
|
|
|
// We want to make sure that there will be no changes to the global state for
|
|
|
|
// the log by synchronising on the XRayBufferIteratorMutex.
|
|
|
|
if (!GlobalXRayImpl)
|
|
|
|
return XRayLogFlushStatus::XRAY_LOG_NOT_FLUSHING;
|
|
|
|
auto Iterator = reinterpret_cast<XRayBuffer (*)(XRayBuffer)>(
|
|
|
|
atomic_load(&XRayBufferIterator, __sanitizer::memory_order_acquire));
|
|
|
|
auto Buffer = (*Iterator)(XRayBuffer{nullptr, 0});
|
|
|
|
auto Mode = CurrentMode ? CurrentMode->Mode : nullptr;
|
|
|
|
while (Buffer.Data != nullptr) {
|
|
|
|
(*Processor)(Mode, Buffer);
|
|
|
|
Buffer = (*Iterator)(Buffer);
|
|
|
|
}
|
|
|
|
return XRayLogFlushStatus::XRAY_LOG_FLUSHED;
|
|
|
|
}
|