[XRay][compiler-rt] XRay Flight Data Recorder Mode


[XRay][compiler-rt] XRay Flight Data Recorder Mode

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


dberrisJan 24 2017, 7:50 PM
Differential Revision
D27038: [XRay][compiler-rt] XRay Flight Data Recorder Mode
rL293014: Driver: ignore -fno-objc-arc-exception when -fno-objc-arc set
jbulow added a subscriber: jbulow.Jan 30 2017, 8:03 AM
jbulow added inline comments.

Is it out of scope to allow emulation of TSC on x86_64? Some virtualized environments, such as FreeBSD's bhyve, does not support TSC.

dberris added inline comments.Jan 31 2017, 12:40 AM

It isn't out of scope, it's just a matter of us not having prioritised that. I'm definitely interested in supporting some sort of emulation that's more apt for x86_64 (see llvm.org/PR31756). It's on my radar and am working on a fix, unless someone beats me to it. :)