| Age | Commit message (Collapse) | Author |
|---|
|
We no longer pass CLANG_DEFAULT_CXX_STDLIB to the runtimes build
as it was causing issues so we can no longer use this variable. We
instead use cxx-headers as a dependency whenever this is available
since both XRay and libFuzzer are built as static libraries so this
is sufficient.
Differential Revision: https://reviews.llvm.org/D49346
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@337199 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The list duplicates information already available in the parent
directory so use that instead. It is unclear to me why we need
to spell out the dependencies explicitly but fixing that should
be done in a separate patch.
Differential Revision: https://reviews.llvm.org/D49177
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@336905 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It turns out that the `${XRAY_HEADERS}` CMake variable was already
in use and was used for public headers. It seems that
`lib/xray/tests/CMakeLists.txt` was depending on this.
To fix rename the new `${XRAY_HEADERS}` to `${XRAY_IMPL_HEADERS}`.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@336699 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
when building with an IDE so that header files show up in the UI.
This massively improves the development workflow in IDEs.
To implement this a new function `compiler_rt_process_sources(...)` has
been added that adds header files to the list of sources when the
generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no
changes are made to the list of source files.
The function can be passed a list of headers via the
`ADDITIONAL_HEADERS` argument. For each runtime library a list of
explicit header files has been added and passed via
`ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of
headers was already present but it was stale and has been updated
to reflect the current state of the source tree.
The original version of this patch used file globbing (`*.{h,inc,def}`)
to find the headers but the approach was changed due to this being a
CMake anti-pattern (if the list of headers changes CMake won't
automatically re-generate if globbing is used).
The LLVM repo contains a similar function named `llvm_process_sources()`
but we don't use it here for several reasons:
* It depends on the `LLVM_ENABLE_OPTION` cache variable which is
not set in standalone compiler-rt builds.
* We would have to `include(LLVMProcessSources)` which I'd like to
avoid because it would include a bunch of stuff we don't need.
Differential Revision: https://reviews.llvm.org/D48422
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@336663 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@334575 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@334469 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@333867 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@333624 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@332313 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@331507 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@331506 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@331141 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@329998 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@329772 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
r319165 introduced a change to CMakeLists.txt for xray where the set of supported
architectures for XRay was iterated over, tested if they could be targeted then
passed to add_compiler_rt_object_libraries. However all targets were passed,
rather than the architecture that was just tested. For cases such as MIPS, where
mips and mips64 are supported, cmake would then test if mips64 could be targetted
resulting in an attempt to produce multiple identical logical target names, falling
afowl of CMP0002.
Reviewers: dberris
Differential Revision: https://reviews.llvm.org/D40890
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319893 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This renames ASM_TSAN_SYMBOL and ASM_TSAN_SYMBOL_INTERCEPTOR to just ASM_SYMBOL and ASM_SYMBOL_INTERCEPTOR, because they can be useful in more places than just TSan. Also introduce a CMake function to add ASM sources to a target.
Differential Revision: https://reviews.llvm.org/D40143
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319339 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rL319241 was a bit too aggressive removing sources dependencies. This
restores the actual required dependency for armhf.
Follow-up to D39114.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319255 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This isolates the per-architecture files from the common files
implementing the XRay facilities. Because of the refactoring done in
D39114, we were including the definition of the sources in the archive
twice, causing link-time failures.
Follow-up to D39114.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319241 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This change is the first in a series of changes to get the XRay runtime
building on macOS. This first allows us to build the minimal parts of
XRay to get us started on supporting macOS development. These include:
- CMake changes to allow targeting x86_64 initially.
- Allowing for building the initialisation routines without
`.preinit_array` support.
- Use __sanitizer::SleepForMillis() to work around the lack of
clock_nanosleep on macOS.
- Deprecate the xray_fdr_log_grace_period_us flag, and introduce
the xray_fdr_log_grace_period_ms flag instead, to use
milliseconds across platforms.
Reviewers: kubamracek
Subscribers: llvm-commits, krytarowski, nglevin, mgorny
Differential Review: https://reviews.llvm.org/D39114
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319165 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts r317875.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@317877 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change implements the changes required in both clang and
compiler-rt to allow building XRay-instrumented binaries in Darwin. For
now we limit this to x86_64. We also start building the XRay runtime
library in compiler-rt for osx.
A caveat to this is that we don't have the tests set up and running
yet, which we'll do in a set of follow-on changes.
This patch uses the monorepo layout for the coordinated change across
multiple projects.
Reviewers: kubamracek
Subscribers: mgorny, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D39114
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@317875 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Breaks build:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/4677/steps/build%20with%20ninja/logs/stdio
In file included from compiler-rt/lib/xray/xray_fdr_logging.cc:34:
In file included from compiler-rt/lib/xray/xray_fdr_logging_impl.h:36:
In file included from compiler-rt/lib/xray/xray_flags.h:18:
compiler-rt/lib/xray/../sanitizer_common/sanitizer_flag_parser.h:23:7: error: '__sanitizer::FlagHandlerBase' has virtual functions but non-virtual destructor [-Werror,-Wnon-virtual-dtor]
class FlagHandlerBase {
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@316348 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Reviewers: dberris, sdardis
Subscribers: jaydeep, bhushan, llvm-commits
Differential Revision: https://reviews.llvm.org/D38021
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@316286 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
initialization.
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@309909 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
collide with the cc file. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@295795 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D29742
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@295251 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: Adds support for xray on mips/mipsel/mips64/mips64el.
Reviewed by sdardis, dberris
Differential: D27699
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@295166 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to only"
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@295097 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
compile on powerpc64le.
I cannot locally reproduce this test failure:
http://lab.llvm.org:8011/builders/sanitizer-ppc64le-linux/builds/1363/steps/test%20standalone%20compiler-rt/logs/stdio
Let's see how the buildbot goes.
Differential Revision: https://reviews.llvm.org/D29742
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@295017 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Revert "Fix -Wsign-compare - this might not be quite right, but preserves behavior"
Revert "[XRay] Implement powerpc64le xray."
This reverts commit r294826.
This reverts commit r294781.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@294842 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
powerpc64 big-endian is not supported, but I believe that most logic can
be shared, except for xray_powerpc64.cc.
Also add a function InvalidateInstructionCache to xray_util.h, which is
copied from llvm/Support/Memory.cpp. I'm not sure if I need to add a unittest,
and I don't know how.
Reviewers: dberris, echristo, iteratee, kbarton, hfinkel
Subscribers: mehdi_amini, nemanjai, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29742
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@294781 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@293015 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts commit https://reviews.llvm.org/rL291734
Reason: mac breakage
http://lab.llvm.org:8080/green//job/clang-stage1-configure-RA_build/28798/consoleFull#1657087648e9a0fee5-ebcc-4238-a641-c5aa112c323e
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@291736 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Subscribers: kubabrecka, mgorny
Differential Revision: https://reviews.llvm.org/D28541
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@291734 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts rL290852 as it breaks aarch64 and arm.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@290854 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@290852 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This implements a simple buffer queue to manage a pre-allocated queue of
fixed-sized buffers to hold XRay records. We need this to support
Flight Data Recorder (FDR) mode. We also implement this as a sub-library
first to allow for development before actually using it in an
implementation.
Some important properties of the buffer queue:
- Thread-safe enqueueing/dequeueing of fixed-size buffers.
- Pre-allocation of buffers at construction.
This is a re-roll of the previous attempt to submit, because it caused
failures in arm and aarch64.
Reviewers: majnemer, echristo, rSerge
Subscribers: tberghammer, danalbert, srhines, modocache, mehdi_amini, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26232
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@288775 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Broke the build on arm7 and aarch64.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@287911 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This implements a simple buffer queue to manage a pre-allocated queue of
fixed-sized buffers to hold XRay records. We need this to support
Flight Data Recorder (FDR) mode. We also implement this as a sub-library
first to allow for development before actually using it in an
implementation.
Some important properties of the buffer queue:
- Thread-safe enqueueing/dequeueing of fixed-size buffers.
- Pre-allocation of buffers at construction.
Reviewers: majnemer, rSerge, echristo
Subscribers: mehdi_amini, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26232
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@287910 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch adds XRay support in compiler-rt for AArch64 targets.
This patch is one of a series:
LLVM: https://reviews.llvm.org/D26412
Clang: https://reviews.llvm.org/D26415
Author: rSerge
Reviewers: rengolin, dberris
Subscribers: aemerson, mgorny, llvm-commits, iid_iunknown
Differential Revision: https://reviews.llvm.org/D26413
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@287517 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Adds a CMake check for whether the compiler used to build the XRay
library supports XRay-instrumentation. If the compiler we're using does
support the `-fxray-instrument` flag (i.e. recently-built Clang), we
define the XRAY_NEVER_INSTRUMENT macro that then makes sure that the
XRay runtime functions never get XRay-instrumented.
This prevents potential weirdness involved with building the XRay
library with a Clang that supports XRay-instrumentation, and is
attempting to XRay-instrument the build of compiler-rt.
Reviewers: majnemer, rSerge, echristo
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D26597
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@287068 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a port of XRay to ARM 32-bit, without Thumb support yet.
This is one of 3 commits to different repositories of XRay ARM port. The other 2 are:
https://reviews.llvm.org/D23931 (LLVM)
https://reviews.llvm.org/D23932 (Clang test)
Differential Revision: https://reviews.llvm.org/D23933
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@281971 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts commit r280890, as the related LLVM commit broke the thumb bots.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@280969 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a port of XRay to ARM 32-bit, without Thumb support yet.
This is one of 3 commits to different repositories of XRay ARM port. The
other 2 are:
1. https://reviews.llvm.org/D23931 (LLVM)
2. https://reviews.llvm.org/D23932 (Clang test)
Differential Revision: https://reviews.llvm.org/D23933
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@280890 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch builds on LLVM r279776.
In this patch I've done some cleanup and abstracted three common steps runtime components have in their CMakeLists files, and added a fourth.
The three steps I abstract are:
(1) Add a top-level target (i.e asan, msan, ...)
(2) Set the target properties for sorting files in IDE generators
(3) Make the compiler-rt target depend on the top-level target
The new step is to check if a command named "runtime_register_component" is defined, and to call it with the component name.
The runtime_register_component command is defined in llvm/runtimes/CMakeLists.txt, and presently just adds the component to a list of sub-components, which later gets used to generate target mappings.
With this patch a new workflow for runtimes builds is supported. The new workflow when building runtimes from the LLVM runtimes directory is:
> cmake [...]
> ninja runtimes-configure
> ninja asan
The "runtimes-configure" target builds all the dependencies for configuring the runtimes projects, and runs CMake on the runtimes projects. Running the runtimes CMake generates a list of targets to bind into the top-level CMake so subsequent build invocations will have access to some of Compiler-RT's targets through the top-level build.
Note: This patch does exclude some top-level targets from compiler-rt libraries because they either don't install files (sanitizer_common), or don't have a cooresponding `check` target (stats).
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@279863 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Depends on D21612 which implements the building blocks for the compiler-rt
implementation of the XRay runtime. We use a naive in-memory log of fixed-size
entries that get written out to a log file when the buffers are full, and when
the thread exits.
This implementation lays some foundations on to allowing for more complex XRay
records to be written to the log in subsequent changes. It also defines the format
that the function call accounting tool in D21987 will start building upon.
Once D21987 lands, we should be able to start defining more tests using that tool
once the function call accounting tool becomes part of the llvm distribution.
Reviewers: echristo, kcc, rnk, eugenis, majnemer, rSerge
Subscribers: sdardis, rSerge, dberris, tberghammer, danalbert, srhines, majnemer, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D21982
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@279805 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@277974 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to extraneous and missing dependencies and attempts to build on unsupported OSes
Summary:
This is a fixed-up version of D21612, to address failure identified post-commit.
Original commit description:
This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting).
Fixes include:
- Gating XRay build to only Linux x86_64 and with the right dependencies in case it is the only library being built
- Including <cstddef> to fix std::size_t issue
Reviewers: kcc, rnk, echristo
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D22611
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@276251 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
runtime"
and also the follow-up "[xray] Only build xray on Linux for now"
Two build errors were reported on the llvm-commits list:
[ 88%] Building CXX object lib/xray/CMakeFiles/clang_rt.xray-x86_64.dir/xray_flags.cc.o
/mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/lib/xray/xray_init.cc:23:10: fatal error: 'llvm/Support/ELF.h' file not found
#include "llvm/Support/ELF.h"
^
and
In file included from /w/src/llvm.org/projects/compiler-rt/lib/xray/xray_interface.cc:16:
/w/src/llvm.org/projects/compiler-rt/lib/xray/xray_interface_internal.h:36:8: error:
no type named 'size_t' in namespace 'std'
std::size_t Entries;
~~~~~^
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@276186 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting).
Depends on D19904
Reviewers: echristo, kcc, rnk
Subscribers: rnk, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D21612
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@276117 91177308-0d34-0410-b5e6-96231b3b80d8
|
