When XRay is being built as part of the just built compiler together
with libc++ as part of the runtimes build, we need an explicit
dependency from XRay to libc++ to make sure that the library is
available by the time we start building XRay.
Differential Revision: https://reviews.llvm.org/D48113
llvm-svn: 334575
Summary:
This is part of the larger XRay Profiling Mode effort.
This patch implements the profile writing mechanism, to allow profiles
collected through the profiler mode to be persisted to files.
Follow-on patches would allow us to load these profiles and start
converting/analysing them through the `llvm-xray` tool.
Depends on D44620.
Reviewers: echristo, kpw, pelikan
Reviewed By: kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45998
llvm-svn: 334472
Summary:
This is part of the larger XRay Profiling Mode effort.
This patch implements the wiring required to enable us to actually
select the `xray-profiling` mode, and install the handlers to start
measuring the time and frequency of the function calls in call stacks.
The current way to get the profile information is by working with the
XRay API to `__xray_process_buffers(...)`.
In subsequent changes we'll implement profile saving to files, similar
to how the FDR and basic modes operate, as well as means for converting
this format into those that can be loaded/visualised as flame graphs. We
will also be extending the accounting tool in LLVM to support
stack-based function call accounting.
We also continue with the implementation to support building small
histograms of latencies for the `FunctionCallTrie::Node` type, to allow
us to actually approximate the distribution of latencies per function.
Depends on D45758 and D46998.
Reviewers: eizan, kpw, pelikan
Reviewed By: kpw
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D44620
llvm-svn: 334469
This change uses 'const' for the retryingWriteAll(...) API and removes
unnecessary 'static' local variables in getting the temporary filename.
llvm-svn: 334267
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
Summary:
This change extracts the recursion guard implementation from FDR Mode
and updates it to do the following:
- Do the atomic operation correctly to be signal-handler safe.
- Make it usable in both FDR and Basic Modes.
Before this change, the recursion guard relied on an unsynchronised read
and write on a volatile thread-local. A signal handler could then run in
between the read and the write, and then be able to run instrumented
code as part of the signal handling. Using an atomic exchange instead
fixes that by doing a proper mutual exclusion even in the presence of
signal handling.
Reviewers: kpw, eizan, jfb
Reviewed By: eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47696
llvm-svn: 334064
We don't actually need to support multiple definitions of the functions
in FDR mode, but rather want to make sure that the implementation-detail
functions are marked as 'static' instead. This allows the inliner to do
its magic better for these functions too, since inline functions must
have a unique address across translation units.
llvm-svn: 334001
We planned to have FDR mode's internals unit-tested but it turns out
that we can just use end-to-end testing to verify the implementation.
We're going to move towards that approach more and more going forward,
so we're merging the implementation details of FDR mode into a single
.cc file.
We also avoid globbing in the XRay test helper macro, and instead list
down the files from the lib directory.
llvm-svn: 333986
Summary:
This is part of the work to address http://llvm.org/PR32274.
We remove the calls to array-placement-new and array-delete. This allows
us to rely on the internal memory management provided by
sanitizer_common/sanitizer_internal_allocator.h.
Reviewers: eizan, kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47695
llvm-svn: 333982
XRay doesn't use RTTI and doesn't need it. We disable it explicitly in
the CMake config, similar to how the other sanitizers already do it.
Part of the work to address http://llvm.org/PR32274.
llvm-svn: 333867
Summary:
This is part of the larger XRay Profiling Mode effort.
This patch implements a centralised collector for `FunctionCallTrie`
instances, associated per thread. It maintains a global set of trie
instances which can be retrieved through the XRay API for processing
in-memory buffers (when registered). Future changes will include the
wiring to implement the actual profiling mode implementation.
This central service provides the following functionality:
* Posting a `FunctionCallTrie` associated with a thread, to the central
list of tries.
* Serializing all the posted `FunctionCallTrie` instances into
in-memory buffers.
* Resetting the global state of the serialized buffers and tries.
Depends on D45757.
Reviewers: echristo, pelikan, kpw
Reviewed By: kpw
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D45758
llvm-svn: 333624
Summary:
This is part of the larger XRay Profiling Mode effort.
This patch implements a central data structure for capturing statistics
about XRay instrumented function call stacks. The `FunctionCallTrie`
type does the following things:
* It keeps track of a shadow function call stack of XRay instrumented
functions as they are entered (function enter event) and as they are
exited (function exit event).
* When a function is entered, the shadow stack contains information
about the entry TSC, and updates the trie (or prefix tree)
representing the current function call stack. If we haven't
encountered this function call before, this creates a unique node for
the function in this position on the stack. We update the list of
callees of the parent function as well to reflect this newly found
path.
* When a function is exited, we compute statistics (TSC deltas,
function call count frequency) for the associated function(s) up the
stack as we unwind to find the matching entry event.
This builds upon the XRay `Allocator` and `Array` types in Part 1 of
this series of patches.
Depends on D45756.
Reviewers: echristo, pelikan, kpw
Reviewed By: kpw
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D45757
llvm-svn: 332313
Summary:
This change allows for handling the in-memory data associated with the
FDR mode implementation through the new `__xray_log_process_buffers`
API. With this change, we can now allow users to process the data
in-memory of the process instead of through writing files.
This for example allows users to stream the data of the FDR logging
implementation through network sockets, or through other mechanisms
instead of saving them to local files.
We introduce an FDR-specific flag, for "no_file_flush" which lets the
flushing logic skip opening/writing to files.
This option can be defaulted to `true` when building the compiler-rt
XRay runtime through the `XRAY_FDR_OPTIONS` preprocessor macro.
Reviewers: kpw, echristo, pelikan, eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46574
llvm-svn: 332208
This change adds some assembler comments to facilitate analysis with
llvm-mca. In particular, we're interested in identifying and later
optimising (reducing) the cost of the key functions in the XRay
implementation using both static analysis (with llvm-mca, etc.) and
dynamic analysis (perf profiling, etc.) of microbenchmarks.
llvm-svn: 331711
Summary:
This addresses http://llvm.org/PR36790.
This change allows the XRay Basic Mode implementation to use the
string-based initialization routine provided through
`__xray_log_init_mode(...)`. In the process, we've also deprecated some
flags defined for the `XRAY_OPTIONS` environment variable.
We then introduce another environment variable that can control the XRay
Basic Mode implementation through `XRAY_BASIC_OPTIONS`.
We also rename files from `xray_inmemory_log` to `xray_basic_logging` to
be more in line with the mode implementation.
Depends on D46174.
Reviewers: echristo, kpw, pelikan, eizan
Reviewed By: kpw
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46246
llvm-svn: 331507
Summary:
In this chage we add support for the string-based configuration
mechanism for configuring FDR mode.
We deprecate most of the `xray_fdr_log_*` flags that are set with the
`XRAY_OPTIONS` environment variable. Instead we make the FDR
implementation take defaults from the `XRAY_FDR_OPTIONS` environment
variable, and use the flags defined in `xray_fdr_flags.{h,cc,inc}` for
the options we support.
This change addresses http://llvm.org/PR36790.
Depends on D46173.
Reviewers: eizan, pelikan, kpw, echristo
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D46174
llvm-svn: 331506
Summary:
This addresses http://llvm.org/PR36790.
The change Deprecates a number of functions and types in
`include/xray/xray_log_interface.h` to recommend using string-based
configuration of XRay through the __xray_log_init_mode(...) function. In
particular, this deprecates the following:
- `__xray_set_log_impl(...)` -- users should instead use the
`__xray_log_register_mode(...)` and `__xray_log_select_mode(...)` APIs.
- `__xray_log_init(...)` -- users should instead use the
`__xray_log_init_mode(...)` function, which also requires using the
`__xray_log_register_mode(...)` and `__xray_log_select_mode(...)`
functionality.
- `__xray::FDRLoggingOptions` -- in following patches, we'll be
migrating the FDR logging implementations (and tests) to use the
string-based configuration. In later stages we'll remove the
`__xray::FDRLoggingOptions` type, and ask users to migrate to using the
string-based configuration mechanism instead.
- `__xray::BasicLoggingOptions` -- same as `__xray::FDRLoggingOptions`,
we'll be removing this type later and instead rely exclusively on the
string-based configuration API.
We also update the documentation to reflect the new advice and remove
some of the deprecated notes.
Reviewers: eizan, kpw, echristo, pelikan
Reviewed By: kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46173
llvm-svn: 331503
Summary:
This change is part of the larger XRay Profiling Mode effort.
Here we implement an arena allocator, for fixed sized buffers used in a
segmented array implementation. This change adds the segmented array
data structure, which relies on the allocator to provide and maintain
the storage for the segmented array.
Key features of the `Allocator` type:
* It uses cache-aligned blocks, intended to host the actual data. These
blocks are cache-line-size multiples of contiguous bytes.
* The `Allocator` has a maximum memory budget, set at construction
time. This allows us to cap the amount of data each specific
`Allocator` instance is responsible for.
* Upon destruction, the `Allocator` will clean up the storage it's
used, handing it back to the internal allocator used in
sanitizer_common.
Key features of the `Array` type:
* Each segmented array is always backed by an `Allocator`, which is
either user-provided or uses a global allocator.
* When an `Array` grows, it grows by appending a segment that's
fixed-sized. The size of each segment is computed by the number of
elements of type `T` that can fit into cache line multiples.
* An `Array` does not return memory to the `Allocator`, but it can keep
track of the current number of "live" objects it stores.
* When an `Array` is destroyed, it will not return memory to the
`Allocator`. Users should clean up the `Allocator` independently of
the `Array`.
* The `Array` type keeps a freelist of the chunks it's used before, so
that trimming and growing will re-use previously allocated chunks.
These basic data structures are used by the XRay Profiling Mode
implementation to implement efficient and cache-aware storage for data
that's typically read-and-write heavy for tracking latency information.
We're relying on the cache line characteristics of the architecture to
provide us good data isolation and cache friendliness, when we're
performing operations like searching for elements and/or updating data
hosted in these cache lines.
Reviewers: echristo, pelikan, kpw
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D45756
llvm-svn: 331141
This code is ill-formed, but under -fno-exceptions compilers generally accept it (at least, prior to C++17). This allows this code to be built by Clang in C++17 mode.
llvm-svn: 330765
Summary:
Typed event patching is implemented for x86-64, but functions must
be defined for other arches.
Reviewers: dberris, pelikan
Subscribers: nemanjai, javed.absar, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45749
llvm-svn: 330231
Summary:
Compiler-rt support first before defining the __xray_typedevent() lowering in
llvm. I'm looking for some early feedback before I touch much more code.
Reviewers: dberris
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43668
llvm-svn: 330218
Summary:
- last change (+ the Apple support change) missed a lot of indentation
- shorten architecture SOURCES definitions as most fit 1 line/arch
- comment in English what's where, and where the different .a come from
(using only the word "runtime" in the comment isn't useful, since the
CMake primitive itself says "runtime" in its name)
- skip unsupported architectures quickly, to avoid extra indentation
Reviewers: dberris, eizan, kpw
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45568
llvm-svn: 329998
Summary:
This patch implements the `-fxray-modes=` flag which allows users
building with XRay instrumentation to decide which modes to pre-package
into the binary being linked. The default is the status quo, which will
link all the available modes.
For this to work we're also breaking apart the mode implementations
(xray-fdr and xray-basic) from the main xray runtime. This gives more
granular control of which modes are pre-packaged, and picked from
clang's invocation.
This fixes llvm.org/PR37066.
Note that in the future, we may change the default for clang to only
contain the profiling implementation under development in D44620, when
that implementation is ready.
Reviewers: echristo, eizan, chandlerc
Reviewed By: echristo
Subscribers: mgorny, mgrang, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D45474
llvm-svn: 329772
Summary:
This is D45125; the patch enables the build of XRay on OpenBSD. We also
introduce some OpenBSD specific changes to the runtime implementation,
involving how we get the TSC rate through the syscall interface specific
to OpenBSD.
Reviewers: dberris
Authored by: devnexen
Subscribers: dberris, mgorny, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D45125
llvm-svn: 329189
Summary:
This change adds APIs to allow logging implementations to provide a
function for iterating through in-memory buffers (if they hold in-memory
buffers) and a way for users to generically deal with these buffers
in-process. These APIs are:
- __xray_log_set_buffer_iterator(...) and
__xray_log_remove_buffer_iterator(): installs and removes an
iterator function that takes an XRayBuffer and yields the next one.
- __xray_log_process_buffers(...): takes a function pointer that can
take a mode identifier (string) and an XRayBuffer to process this
data as they see fit.
The intent is to have the FDR mode implementation's buffers be
available through this `__xray_log_process_buffers(...)` API, so that
they can be streamed from memory instead of flushed to disk (useful for
getting the data to a network, or doing in-process analysis).
Basic mode logging will not support this mechanism as it's designed to
write the data mostly to disk.
Future implementations will may depend on this API as well, to allow for
programmatically working through the XRay buffers exposed to the
users in some fashion.
Reviewers: eizan, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43495
llvm-svn: 326866
Summary:
This change makes changes to XRay implementation files trigger re-builds
of the unit tests. Prior to this change, the unit tests were not built
and run properly if the implementation files were changed during the
development process. This change forces the dependency on all files in
the XRay include and lib hosted files in compiler-rt.
Caveat is, that new files added to the director(ies) will need a re-run
of CMake to re-generate the fileset.
We think this is an OK compromise, since adding new files may
necessitate editing (or adding) new unit tests. It's also less likely
that we're adding new files without updating the CMake configuration to
include the functionality in the XRay runtime implementation anyway.
Reviewers: pelikan, kpw, nglevin
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D44080
llvm-svn: 326842
Summary:
- Enabling the build.
- Using assembly for the cpuid parts.
- Using thr_self FreeBSD call to get the thread id
Patch by: David CARLIER
Reviewers: dberris, rnk, krytarowski
Reviewed By: dberris, krytarowski
Subscribers: emaste, stevecheckoway, nglevin, srhines, kubamracek, dberris, mgorny, krytarowski, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43278
llvm-svn: 325240
Summary:
Allow for options to be defined at compile time, like is already the case for
other sanitizers, via `SCUDO_DEFAULT_OPTIONS`.
Reviewers: alekseyshl, dberris
Reviewed By: alekseyshl, dberris
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42980
llvm-svn: 324620
Summary:
This change expands the amount of registers stashed by the entry and
`__xray_CustomEvent` trampolines.
We've found that since the `__xray_CustomEvent` trampoline calls can show up in
situations where the scratch registers are being used, and since we don't
typically want to affect the code-gen around the disabled
`__xray_customevent(...)` intrinsic calls, that we need to save and restore the
state of even the scratch registers in the handling of these custom events.
Reviewers: pcc, pelikan, dblaikie, eizan, kpw, echristo, chandlerc
Reviewed By: echristo
Subscribers: chandlerc, echristo, hiraditya, davide, dblaikie, llvm-commits
Differential Revision: https://reviews.llvm.org/D40894
llvm-svn: 323940
Summary:
While there, unify InMemoryRawLog and InMemoryRawLogWithArg's coding style:
- swap libc's memcpy(3) for sanitizer's internal memcpy
- use basic pointer arithmetics to compute offsets from the first record
entry in the pre-allocated buffer, which is always the appropriate type
for the given function
- lose the local variable references as the TLD.* names fit just as well
Reviewers: eizan, kpw, dberris, dblaikie
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42289
llvm-svn: 322941
Fangrui Song