maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/compiler-rt/lib/xray/CMakeLists.txt

67 lines
1.4 KiB
CMake
Raw Normal View History

[compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due 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 llvm-svn: 276251
2016-07-21 15:39:55 +08:00
# Build for the XRay runtime support library.
[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 runtime library implementation files.
[compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due 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 llvm-svn: 276251
2016-07-21 15:39:55 +08:00
set(XRAY_SOURCES
[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_inmemory_log.cc
[compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due 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 llvm-svn: 276251
2016-07-21 15:39:55 +08:00
xray_init.cc
Revert "[XRay][compiler-rt] XRay Flight Data Recorder Mode" This reverts rL290852 as it breaks aarch64 and arm. llvm-svn: 290854
2017-01-03 12:04:00 +08:00
xray_flags.cc
[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_interface.cc
xray_buffer_queue.cc
xray_log_interface.cc
xray_fdr_logging.cc
xray_utils.cc)
[compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due 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 llvm-svn: 276251
2016-07-21 15:39:55 +08:00
set(x86_64_SOURCES
[XRay][compiler-rt] Disable XRay instrumentation of the XRay runtime. 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 llvm-svn: 287068
2016-11-16 09:01:13 +08:00
xray_x86_64.cc
xray_trampoline_x86_64.S
${XRAY_SOURCES})
[compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due 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 llvm-svn: 276251
2016-07-21 15:39:55 +08:00
[XRay] ARM 32-bit no-Thumb support in compiler-rt 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 llvm-svn: 281971
2016-09-20 22:35:57 +08:00
set(arm_SOURCES
[XRay][compiler-rt] Disable XRay instrumentation of the XRay runtime. 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 llvm-svn: 287068
2016-11-16 09:01:13 +08:00
xray_arm.cc
xray_trampoline_arm.S
${XRAY_SOURCES})
[XRay] ARM 32-bit no-Thumb support in compiler-rt 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 llvm-svn: 281971
2016-09-20 22:35:57 +08:00
[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
set(armhf_SOURCES
${arm_SOURCES})
[XRay] ARM 32-bit no-Thumb support in compiler-rt 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 llvm-svn: 281971
2016-09-20 22:35:57 +08:00
[XRay] Support AArch64 in compiler-rt 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 llvm-svn: 287517
2016-11-21 11:20:43 +08:00
set(aarch64_SOURCES
[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_AArch64.cc
xray_trampoline_AArch64.S
${XRAY_SOURCES})
[XRay] Support AArch64 in compiler-rt 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 llvm-svn: 287517
2016-11-21 11:20:43 +08:00
[compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due 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 llvm-svn: 276251
2016-07-21 15:39:55 +08:00
include_directories(..)
include_directories(../../include)
set(XRAY_CFLAGS ${SANITIZER_COMMON_CFLAGS})
set(XRAY_COMMON_DEFINITIONS XRAY_HAS_EXCEPTIONS=1)
[XRay][compiler-rt] Disable XRay instrumentation of the XRay runtime. 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 llvm-svn: 287068
2016-11-16 09:01:13 +08:00
append_list_if(
COMPILER_RT_HAS_XRAY_COMPILER_FLAG XRAY_SUPPORTED=1 XRAY_COMMON_DEFINITIONS)
[compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due 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 llvm-svn: 276251
2016-07-21 15:39:55 +08:00
add_compiler_rt_object_libraries(RTXray
[XRay][compiler-rt] XRay Buffer Queue 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 llvm-svn: 288775
2016-12-06 14:24:08 +08:00
ARCHS ${XRAY_SUPPORTED_ARCH}
SOURCES ${XRAY_SOURCES} CFLAGS ${XRAY_CFLAGS}
DEFS ${XRAY_COMMON_DEFINITIONS})
[CMake] Connect Compiler-RT targets to LLVM Runtimes directory 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). llvm-svn: 279863
2016-08-27 04:52:22 +08:00
add_compiler_rt_component(xray)
[compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due 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 llvm-svn: 276251
2016-07-21 15:39:55 +08:00
set(XRAY_COMMON_RUNTIME_OBJECT_LIBS
[XRay][compiler-rt] Disable XRay instrumentation of the XRay runtime. 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 llvm-svn: 287068
2016-11-16 09:01:13 +08:00
RTSanitizerCommon
Revert "[sancov] moving sancov rt to sancov/ directory" 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 llvm-svn: 291736
2017-01-12 09:37:35 +08:00
RTSanitizerCommonLibc)
[compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due 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 llvm-svn: 276251
2016-07-21 15:39:55 +08:00
[XRay][compiler-rt] XRay Buffer Queue 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 llvm-svn: 288775
2016-12-06 14:24:08 +08:00
foreach(arch ${XRAY_SUPPORTED_ARCH})
if(CAN_TARGET_${arch})
add_compiler_rt_runtime(clang_rt.xray
STATIC
ARCHS ${arch}
SOURCES ${${arch}_SOURCES}
CFLAGS ${XRAY_CFLAGS}
DEFS ${XRAY_COMMON_DEFINITIONS}
OBJECT_LIBS ${XRAY_COMMON_RUNTIME_OBJECT_LIBS}
PARENT_TARGET xray)
endif()
[compiler-rt][XRay] re-submitting r276117, with fixes for build breakage due 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 llvm-svn: 276251
2016-07-21 15:39:55 +08:00
endforeach()
[XRay][compiler-rt] XRay Buffer Queue 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 llvm-svn: 288775
2016-12-06 14:24:08 +08:00
if(COMPILER_RT_INCLUDE_TESTS)
add_subdirectory(tests)
endif()