Summary:
Before this change, the recursion guard for the flight data recorder
(FDR) mode handlers were independent. This change makes it so that when
a handler is already in the process of running and somehow the same or
another handler starts running -- say in a signal handler, while the
XRay handler is executing -- then we can use the same thread-local
recursion guard to stop the second handler from running.
Reviewers: kpw, eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37612
llvm-svn: 312992
Summary:
Before this change we seemed to not be running the unit tests, and therefore we
set out to run them. In the process of making this happen we found a divergence
between the implementation and the tests.
This includes changes to both the CMake files as well as the implementation and
headers of the XRay runtime. We've also updated documentation on the changed
functions.
Reviewers: kpw, eizan
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D37290
llvm-svn: 312202
Summary:
This change hides all the initialization of thread_local variables used
by the XRay FDR mode implementation behind a function call. This makes
initialization of thread-local data to be done lazily, instead of
eagerly when they're done as globals. It also gives us an isolation
mechanism if/when we want to change the TLS implementation from using
the C++ thread_local keyword, for something more ad-hoc (potentialy
using pthread directly) on some platforms or set-ups where we cannot use
the C++ thread_local variables.
Reviewers: kpw, eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37248
llvm-svn: 311997
Summary:
XRay has erroneously been returning the address of the first sled in the
instrumentation map for a function id instead of the (runtime-relocated)
functison address. This causes confusion and issues for applications
where:
- The first sled in the function may not be an entry sled (due to
re-ordering or some other reason).
- The caller attempts to find a symbol associated with the pointer at
runtime, because the sled may not be exactly where the function's
known address is (in case of inlined functions or those that have an
external definition for symbols).
This fixes http://llvm.org/PR34340.
Reviewers: eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37202
llvm-svn: 311871
Summary:
This change introduces versions to the instrumentation map entries we
emit for XRay instrumentaiton points. The status quo for the version is
currently set to 0 (as emitted by the LLVM back-end), and versions will
count up to 255 (unsigned char).
This change is in preparation for supporting the newer version of the
custom event sleds that will be emitted by the LLVM compiler.
While we're here, we take the opportunity to stash more registers and
align the stack properly in the __xray_CustomEvent trampoline.
Reviewers: kpw, pcc, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36816
llvm-svn: 311524
into a function.
Most CMake configuration under compiler-rt/lib/*/tests have
almost-the-same-but-not-quite functions of the form add_X_[unit]tests
for compiling and running the tests.
Much of the logic is duplicated with minor variations across different
sub-folders.
This can harm productivity for multiple reasons:
For newcomers, resulting CMake files are very large, hard to understand,
and hide the intention of the code.
Changes for enabling certain architectures end up being unnecessarily
large, as they get duplicated across multiple folders.
Adding new sub-projects requires more effort than it should, as a
developer has to again copy-n-paste the configuration, and it's not even
clear from which sub-project it should be copy-n-pasted.
With this change the logic of compile-and-generate-a-set-of-tests is
extracted into a function, which hopefully makes writing and reading
CMake much easier.
Differential Revision: https://reviews.llvm.org/D36116
llvm-svn: 310971
Summary:
Define a build-time configuration option for the XRay runtime to
determine whether the archive will add an entry to the `.preinit_array`
section of the binary. We also allow for initializing the XRay data
structures with an explicit call to __xray_init(). This allows us to
give users the capability to initialize the XRay data structures on
demand.
This can allow us to start porting XRay to platforms where
`.preinit_array` isn't a supported section. It also allows us to limit
the effects of XRay in the initialization sequence for applications that
are sensitive to this kind of interference (i.e. large binaries) or
those that want to package XRay control in libraries.
Future changes should allow us to build two different library archives
for the XRay runtime, and allow clang users to determine which version
to link.
Reviewers: dblaikie, kpw, pelikan
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D36080
llvm-svn: 309909
Summary:
This change attempts to remove all the dependencies we have on
std::mutex and any std::shared_ptr construction in global variables. We
instead use raw pointers to these objects, and construct them on the
heap. In cases where it's possible, we lazily initialize these pointers.
While we do not have a replacement for std::shared_ptr yet in
compiler-rt, we use this work-around to avoid having to statically
initialize the objects as globals. Subsequent changes should allow us to
completely remove our dependency on std::shared_ptr and instead have our
own implementation of the std::shared_ptr and std::weak_ptr semantics
(or completely rewrite the implementaton to not need these
standard-library provided abstractions).
Reviewers: dblaikie, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36078
llvm-svn: 309792
Summary:
Currently when the XRay runtime is linked into a binary that doesn't
have the instrumentation map, we print a warning unconditionally. This
change attempts to make this behaviour more quiet.
Reviewers: kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35789
llvm-svn: 309534
Currently there's a large amount of CMake logic duplication for
compiling sanitizer tests.
If we add more sanitizers, the duplication will get even worse.
This change factors out common compilation commands into a macro
available to all sanitizers.
llvm-svn: 309405
Summary:
This change introduces two files that show exaples of the
always/never instrument files that can be provided to clang. We don't
add these as defaults yet in clang, which we can do later on (in a
separate change).
We also add a test that makes sure that these apply in the compiler-rt
project tests, and that changes in clang don't break the expectations in
compiler-rt.
Reviewers: pelikan, kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34669
llvm-svn: 306502
Summary:
This change implements support for the custom event logging sleds and
intrinsics at runtime. For now it only supports handling the sleds in
x86_64, with the implementations for other architectures stubbed out to
do nothing.
NOTE: Work in progress, uploaded for exposition/exploration purposes.
Depends on D27503, D30018, and D33032.
Reviewers: echristo, javed.absar, timshen
Subscribers: mehdi_amini, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D30630
llvm-svn: 302857
Summary:
This bug is caused by the incorrect handling of return-value registers.
According to OpenPOWER 64-Bit ELF V2 ABI 2.2.5, up to 2 general-purpose
registers are going to be used for return values, and up to 8 floating
point registers or vector registers are going to be used for return
values.
Reviewers: dberris, echristo
Subscribers: nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D33027
llvm-svn: 302691
Summary:
This change allows us to provide users and implementers of XRay handlers
a means of converting XRay function id's to addresses. This, in
combination with the facilities provided in D32695, allows users to find
out:
- How many function id's there are defined in the current binary.
- Get the address of the function associated with this function id.
- Patch only specific functions according to their requirements.
While we don't directly provide symbolization support in XRay, having
the function's address lets users determine this information easily
either during runtime, or offline with tools like 'addr2line'.
Reviewers: dblaikie, echristo, pelikan
Subscribers: kpw, llvm-commits
Differential Revision: https://reviews.llvm.org/D32846
llvm-svn: 302210
Summary:
This change allows us to patch/unpatch specific functions using the
function ID. This is useful in cases where implementations might want to
do coverage-style, or more fine-grained control of which functions to
patch or un-patch at runtime.
Depends on D32693.
Reviewers: dblaikie, echristo, kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32695
llvm-svn: 302112
Summary:
In this patch we document the requirements for implementations that want
to install handlers for the dynamically-controlled XRay "framework".
This clarifies what the expectations are for implementations that
want to install their handlers using this API (similar to how the FDR
logging implementation does so). It also gives users some guarantees on
semantics for the APIs.
If all goes well, users can decide to use the XRay APIs to control the
tracing/logging at the application level, without having to depend on
implementation details of the installed logging implementation. This
lets users choose the implementation that comes with compiler-rt, or
potentially multiple other implementations that use the same APIs.
We also add one convenience function (__xray_remove_log_impl()) for
explicitly removing the currently installed log implementation.
Reviewers: kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32579
llvm-svn: 301784
Summary:
This is a follow-up to D32202.
While the previous change (D32202) did fix the stack alignment issue, we
were still at a weird state in terms of the CFI/CFA directives (as the
offsets were wrong). This change cleans up the SAVE/RESTORE macros for
the trampoline, accounting the stack pointer adjustments with less
instructions and with some clearer math. We note that the offsets will
be different on the exit trampolines, because we don't typically 'call'
into this trampoline and we only ever jump into them (i.e. treated as a
tail call that's patched in at runtime).
Reviewers: eugenis, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32214
llvm-svn: 300815
Summary:
Previously, we had been very undisciplined about CFI annotations with
the XRay trampolines. This leads to runtime crashes due to mis-alined
stack pointers that some function implementations may run into (i.e.
those using instructions that require properly aligned addresses coming
from the stack). This patch attempts to clean that up, as well as more
accurately use the correct amounts of space on the stack for stashing
and un-stashing registers.
Reviewers: eugenis, kcc
Subscribers: kpw, llvm-commits
Differential Revision: https://reviews.llvm.org/D32202
llvm-svn: 300660
A problem arises if a machine supports the rdtscp instruction, but the processor
frequency cannot be determined by the function getTSCFrequency(). In this case,
we want to use the emulated TSC instead. This patch implements that by adding a
call to getTSCFrequency() from probeRequiredCPUFeatures(), and the function only
returns true if both the processor supports rdtscp and the CPU frequency can be
determined.
This should fix PR32620.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32067
llvm-svn: 300525
Summary:
While there, make the threshold in ticks for the rewind computed only
once and not per function, unify the two versions we had and slightly
reformat bits according to coding standards.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31971
llvm-svn: 300028
Summary:
Not repeating screamy failure paths makes the 300+ line function a bit shorter.
There's no need to overload the variable name "Buffer" if it only works on the
thread local buffer. Fix some comments while there.
I plan to move the rewinding logic into a separate function too, but in this
diff it would be too much of a mess to comprehend. This is trivially NFC.
Reviewers: kpw, dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31930
llvm-svn: 300018
This patch applies a work-around to the XRay FDR tests when TSC emulation is
needed because the processor frequency cannot be determined.
This fixes PR32620 using the suggestion given by Dean in comment 1.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31967
llvm-svn: 300017
Previously in r297800, a work-around was created to use TSC emulation on x86_64 when RDTSCP was not available on the host. A similar change was needed in the file xray_fdr_logging.cc which this patch ports over to that file.
Eventually the code should be refactored as there will be 3 locations with the same code, but that can be done as a separate step. This patch is just to keep the test from failing on my machine due to an illegal instruction since RDTSCP is not available on my x86_64 linux VM.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31909
llvm-svn: 299922
Summary:
We can move this functionality into LLVM's tools instead, as it no
longer is strictly required for the compiler-rt testing infrastructure.
It also is blocking the successful bootstrapping of the clang compiler
due to a missing virtual destructor in one of the flag parsing library.
Since this binary isn't critical for the XRay runtime testing effort
anymore (yet), we remove it in the meantime with the hope of moving the
functionality in LLVM proper instead.
Reviewers: kpw, pelikan, rnk, seurer, eugenis
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31926
llvm-svn: 299916
Summary:
"short" is defined as an xray flag, and buffer rewinding happens for both exits
and tail exits.
I've made the choice to seek backwards finding pairs of FunctionEntry, TailExit
record pairs and erasing them if the FunctionEntry occurred before exit from the
currently exiting function. This is a compromise so that we don't skip logging
tail calls if the function that they call into takes longer our duration.
This works by counting the consecutive function and function entry, tail exit
pairs that proceed the current point in the buffer. The buffer is rewound to
check whether these entry points happened recently enough to be erased.
It is still possible we will omit them if they call into a child function that
is not instrumented which calls a fast grandchild that is instrumented before
doing other processing.
Reviewers: pelikan, dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31345
llvm-svn: 299629
Summary:
Currently the FDR log writer, upon flushing, dumps a sequence of buffers from
its freelist to disk. A reader can read the first buffer up to an EOB record,
but then it is unclear how far ahead to scan to find the next threads traces.
There are a few ways to handle this problem.
1. The reader has externalized knowledge of the buffer size.
2. The size of buffers is in the file header or otherwise encoded in the log.
3. Only write out the portion of the buffer with records. When released, the
buffers are marked with a size.
4. The reader looks for memory that matches a pattern and synchronizes on it.
2 and 3 seem the most flexible and 2 does not rule 3 out.
This is an implementation of 2.
In addition, the function handler for fdr more aggressively checks for
finalization and makes an attempt to release its buffer.
Reviewers: pelikan, dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31384
llvm-svn: 298982
Summary:
This change exercises the end-to-end functionality defined in the FDR
logging implementation. We also prepare for being able to run traces
generated by the FDR logging implementation from being analysed with the
llvm-xray command that comes with the LLVM distribution.
This also unblocks D31385, D31384, and D31345.
Reviewers: kpw, pelikan
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31452
llvm-svn: 298977
In file included from /home/abuild/rpmbuild/BUILD/llvm/projects/compiler-rt/lib/xray/tests/unit/xray_fdr_log_printer_tool.cc:15:
../projects/compiler-rt/lib/xray/tests/../xray_fdr_logging_impl.h:221:21: error: use of undeclared identifier 'CLOCK_MONOTONIC'
wall_clock_reader(CLOCK_MONOTONIC, &TS);
^
1 error generated.
llvm-svn: 298837
Instead of std::atomic APIs for atomic operations, we instead use APIs
include with sanitizer_common. This allows us to, at runtime, not have
to depend on potentially dynamically provided implementations of these
atomic operations.
Fixes http://llvm.org/PR32274.
llvm-svn: 298833
Summary: Fd needs to be closed before the number gets out of scope.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31278
llvm-svn: 298685
Summary:
Depending on C++11 <system_error> introduces a link-time requirement to
C++11 symbols. Removing it allows us to depend on header-only C++11 and
up libraries.
Partially fixes http://llvm.org/PR32274 -- we know there's more invasive work
to be done, but we're doing it incrementally.
Reviewers: dblaikie, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31233
llvm-svn: 298480
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
Summary:
Use TSC emulation in cases where RDTSCP isn't available on the host
running an XRay instrumented binary. We can then fall back into
emulation instead of not even installing XRay's runtime functionality.
We only do this for now in the naive/basic logging implementation, but
should be useful in even FDR mode.
Should fix http://llvm.org/PR32148.
Reviewers: pelikan, rnk, sdardis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30677
llvm-svn: 297800
rL297000 forgot to include code for three architectures that appeared
since I wrote the first version. This gives them the same treatment as ARMs
have for now - write stubs and wait for someone to actually implement it.
Patched by pelikan (Martin Pelikán)!
Differential Revision: https://reviews.llvm.org/D30634
llvm-svn: 297003
Summary:
Functions with the LOG_ARGS_ENTRY sled kind at their beginning will be handled
in a way to (optionally) pass their first call argument to your logging handler.
For practical and performance reasons, only the first argument is supported, and
only up to 64 bits.
Reviewers: javed.absar, dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29703
llvm-svn: 297000
Summary:
Use a common definition of a "this variable is unused" annotation for useless
variables only present for their lambda global initializers, to silence gcc's
warning.
Reviewers: dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29860
llvm-svn: 296449
Summary:
Currently, we assume that applications built with XRay would like to
have the instrumentation sleds patched before main starts. This patch
changes the default so that we do not patch the instrumentation sleds
before main. This default is more helpful for deploying applications in
environments where changing the current default is harder (i.e. on
remote machines, or work-pool-like systems).
This default (not to patch pre-main) makes it easier to selectively run
applications with XRay instrumentation enabled, than with the current
state.
Reviewers: echristo, timshen
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D30396
llvm-svn: 296445
Dean Michael Berris