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

181 lines
4.9 KiB
CMake
Raw Normal View History

[XRay] [compiler-rt] reformat and clarify CMakeLists.txt [NFC] 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
2018-04-13 16:33:46 +08:00
# Build for all components of the XRay runtime support library.
[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 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][profiler] Part 1: XRay Allocator and Array Implementations 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
2018-04-29 21:46:30 +08:00
xray_init.cc
xray_flags.cc
xray_interface.cc
xray_log_interface.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
[XRay] [compiler-rt] reformat and clarify CMakeLists.txt [NFC] 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
2018-04-13 16:33:46 +08:00
# Implementation files for all XRay modes.
[XRay][clang+compiler-rt] Support build-time mode selection 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
2018-04-11 09:28:25 +08:00
set(XRAY_FDR_MODE_SOURCES
[XRay][profiler] Part 1: XRay Allocator and Array Implementations 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
2018-04-29 21:46:30 +08:00
xray_buffer_queue.cc
xray_fdr_logging.cc)
[XRay][clang+compiler-rt] Support build-time mode selection 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
2018-04-11 09:28:25 +08:00
set(XRAY_BASIC_MODE_SOURCES
[XRay][profiler] Part 1: XRay Allocator and Array Implementations 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
2018-04-29 21:46:30 +08:00
xray_inmemory_log.cc)
[XRay][clang+compiler-rt] Support build-time mode selection 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
2018-04-11 09:28:25 +08:00
[XRay] [compiler-rt] reformat and clarify CMakeLists.txt [NFC] 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
2018-04-13 16:33:46 +08:00
# Implementation files for all XRay architectures.
[XRay][profiler] Part 1: XRay Allocator and Array Implementations 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
2018-04-29 21:46:30 +08:00
set(x86_64_SOURCES
xray_x86_64.cc
xray_trampoline_x86_64.S)
set(arm_SOURCES
xray_arm.cc
xray_trampoline_arm.S)
set(armhf_SOURCES
${arm_SOURCES})
set(aarch64_SOURCES
xray_AArch64.cc
xray_trampoline_AArch64.S)
set(mips_SOURCES
xray_mips.cc
xray_trampoline_mips.S)
set(mipsel_SOURCES
xray_mips.cc
xray_trampoline_mips.S)
set(mips64_SOURCES
xray_mips64.cc
xray_trampoline_mips64.S)
set(mips64el_SOURCES
xray_mips64.cc
xray_trampoline_mips64.S)
Re-commit r295017, since we have a potential fix of the tests, r295248, landed. Differential Revision: https://reviews.llvm.org/D29742 llvm-svn: 295251
2017-02-16 06:40:29 +08:00
set(powerpc64le_SOURCES
[XRay][compiler-rt] Fix runtime build 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. llvm-svn: 319241
2017-11-29 06:33:07 +08:00
xray_powerpc64.cc
xray_trampoline_powerpc64.cc
xray_trampoline_powerpc64_asm.S)
Re-commit r295017, since we have a potential fix of the tests, r295248, landed. Differential Revision: https://reviews.llvm.org/D29742 llvm-svn: 295251
2017-02-16 06:40:29 +08:00
[XRay] [compiler-rt] reformat and clarify CMakeLists.txt [NFC] 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
2018-04-13 16:33:46 +08:00
# Now put it all together...
[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)
[XRay][compiler-rt] Allow for building the XRay runtime without PREINIT 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 llvm-svn: 309909
2017-08-03 08:58:45 +08:00
append_list_if(
COMPILER_RT_BUILD_XRAY_NO_PREINIT XRAY_NO_PREINIT 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
[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][Darwin] Minimal XRay build support in Darwin 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 llvm-svn: 319165
2017-11-28 19:49:22 +08:00
if (APPLE)
set(XRAY_LINK_LIBS ${SANITIZER_COMMON_LINK_LIBS})
[sanitizer] Refactor how assembly files are handled 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 llvm-svn: 319339
2017-11-30 03:27:25 +08:00
add_asm_sources(XRAY_ASM_SOURCES xray_trampoline_x86_64.S)
[XRay][compiler-rt][Darwin] Minimal XRay build support in Darwin 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 llvm-svn: 319165
2017-11-28 19:49:22 +08:00
add_weak_symbols("sanitizer_common" WEAK_SYMBOL_LINK_FLAGS)
add_weak_symbols("xray" WEAK_SYMBOL_LINK_FLAGS)
add_compiler_rt_object_libraries(RTXray
OS ${XRAY_SUPPORTED_OS}
ARCHS ${XRAY_SUPPORTED_ARCH}
SOURCES ${x86_64_SOURCES}
CFLAGS ${XRAY_CFLAGS}
DEFS ${XRAY_COMMON_DEFINITIONS})
[XRay][clang+compiler-rt] Support build-time mode selection 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
2018-04-11 09:28:25 +08:00
add_compiler_rt_object_libraries(RTXrayFDR
OS ${XRAY_SUPPORTED_OS}
ARCHS ${XRAY_SUPPORTED_ARCH}
SOURCES ${XRAY_FDR_MODE_SOURCES}
CFLAGS ${XRAY_CFLAGS}
DEFS ${XRAY_COMMON_DEFINITIONS})
add_compiler_rt_object_libraries(RTXrayBASIC
OS ${XRAY_SUPPORTED_OS}
ARCHS ${XRAY_SUPPORTED_ARCH}
SOURCES ${XRAY_BASIC_MODE_SOURCES}
CFLAGS ${XRAY_CFLAGS}
DEFS ${XRAY_COMMON_DEFINITIONS})
[XRay][compiler-rt][Darwin] Minimal XRay build support in Darwin 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 llvm-svn: 319165
2017-11-28 19:49:22 +08:00
# We only support running on osx for now.
add_compiler_rt_runtime(clang_rt.xray
STATIC
OS ${XRAY_SUPPORTED_OS}
ARCHS ${XRAY_SUPPORTED_ARCH}
OBJECT_LIBS RTXray
RTSanitizerCommon
RTSanitizerCommonLibc
CFLAGS ${XRAY_CFLAGS}
DEFS ${XRAY_COMMON_DEFINITIONS}
LINK_FLAGS ${SANITIZER_COMMON_LINK_FLAGS} ${WEAK_SYMBOL_LINK_FLAGS}
LINK_LIBS ${XRAY_LINK_LIBS}
PARENT_TARGET xray)
[XRay][clang+compiler-rt] Support build-time mode selection 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
2018-04-11 09:28:25 +08:00
add_compiler_rt_runtime(clang_rt.xray-fdr
STATIC
OS ${XRAY_SUPPORTED_OS}
ARCHS ${XRAY_SUPPORTED_ARCH}
OBJECT_LIBS RTXrayFDR
CFLAGS ${XRAY_CFLAGS}
DEFS ${XRAY_COMMON_DEFINITIONS}
LINK_FLAGS ${SANITIZER_COMMON_LINK_FLAGS} ${WEAK_SYMBOL_LINK_FLAGS}
LINK_LIBS ${XRAY_LINK_LIBS}
PARENT_TARGET xray)
add_compiler_rt_runtime(clang_rt.xray-basic
STATIC
OS ${XRAY_SUPPORTED_OS}
ARCHS ${XRAY_SUPPORTED_ARCH}
OBJECT_LIBS RTXrayBASIC
CFLAGS ${XRAY_CFLAGS}
DEFS ${XRAY_COMMON_DEFINITIONS}
LINK_FLAGS ${SANITIZER_COMMON_LINK_FLAGS} ${WEAK_SYMBOL_LINK_FLAGS}
LINK_LIBS ${XRAY_LINK_LIBS}
PARENT_TARGET xray)
[XRay] [compiler-rt] reformat and clarify CMakeLists.txt [NFC] 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
2018-04-13 16:33:46 +08:00
else() # not Apple
foreach(arch ${XRAY_SUPPORTED_ARCH})
if(NOT CAN_TARGET_${arch})
continue()
endif()
[XRay][compiler-rt][Darwin] Minimal XRay build support in Darwin 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 llvm-svn: 319165
2017-11-28 19:49:22 +08:00
add_compiler_rt_object_libraries(RTXray
[compiler-rt][xray][cmake] Fix a build issue caused by set/item mixup 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 llvm-svn: 319893
2017-12-06 22:03:41 +08:00
ARCHS ${arch}
[XRay][clang+compiler-rt] Support build-time mode selection 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
2018-04-11 09:28:25 +08:00
SOURCES ${XRAY_SOURCES} ${${arch}_SOURCES} CFLAGS ${XRAY_CFLAGS}
[XRay][compiler-rt][Darwin] Minimal XRay build support in Darwin 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 llvm-svn: 319165
2017-11-28 19:49:22 +08:00
DEFS ${XRAY_COMMON_DEFINITIONS})
[XRay][clang+compiler-rt] Support build-time mode selection 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
2018-04-11 09:28:25 +08:00
add_compiler_rt_object_libraries(RTXrayFDR
ARCHS ${arch}
SOURCES ${XRAY_FDR_MODE_SOURCES} CFLAGS ${XRAY_CFLAGS}
DEFS ${XRAY_COMMON_DEFINITIONS})
add_compiler_rt_object_libraries(RTXrayBASIC
ARCHS ${arch}
SOURCES ${XRAY_BASIC_MODE_SOURCES} CFLAGS ${XRAY_CFLAGS}
DEFS ${XRAY_COMMON_DEFINITIONS})
[XRay] [compiler-rt] reformat and clarify CMakeLists.txt [NFC] 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
2018-04-13 16:33:46 +08:00
# Common XRay archive for instrumented binaries.
[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
add_compiler_rt_runtime(clang_rt.xray
STATIC
ARCHS ${arch}
Revert "[Compiler-rt][MIPS] Fix cross build for XRAY." 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 { llvm-svn: 316348
2017-10-24 01:13:24 +08:00
CFLAGS ${XRAY_CFLAGS}
[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
DEFS ${XRAY_COMMON_DEFINITIONS}
[XRay][clang+compiler-rt] Support build-time mode selection 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
2018-04-11 09:28:25 +08:00
OBJECT_LIBS ${XRAY_COMMON_RUNTIME_OBJECT_LIBS} RTXray
PARENT_TARGET xray)
[XRay] [compiler-rt] reformat and clarify CMakeLists.txt [NFC] 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
2018-04-13 16:33:46 +08:00
# FDR mode runtime archive (addon for clang_rt.xray)
add_compiler_rt_runtime(clang_rt.xray-fdr
STATIC
ARCHS ${arch}
CFLAGS ${XRAY_CFLAGS}
DEFS ${XRAY_COMMON_DEFINITIONS}
OBJECT_LIBS RTXrayFDR
PARENT_TARGET xray)
# Basic mode runtime archive (addon for clang_rt.xray)
add_compiler_rt_runtime(clang_rt.xray-basic
STATIC
ARCHS ${arch}
CFLAGS ${XRAY_CFLAGS}
DEFS ${XRAY_COMMON_DEFINITIONS}
OBJECT_LIBS RTXrayBASIC
PARENT_TARGET xray)
endforeach()
endif() # not Apple
[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()