| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[NFC][sanitizer] Move ArrayRef into own header | 3 年前 | |
[CMake] Use libcxx-abi-* targets for in-tree sanitizer C++ ABI When in-tree libcxx is selected as the sanitizer C++ ABI, use libcxx-abi-* targets rather than libcxxabi and libunwind directly. Differential Revision: https://reviews.llvm.org/D134855 | 3 年前 | |
[MemProf] Memory profiling runtime support See RFC for background: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html Follow on companion to the clang/llvm instrumentation support in D85948 and committed earlier. This patch adds the compiler-rt runtime support for the memory profiling. Note that much of this support was cloned from asan (and then greatly simplified and renamed). For example the interactions with the sanitizer_common allocators, error handling, interception, etc. The bulk of the memory profiling specific code can be found in the MemInfoBlock, MemInfoBlockCache, and related classes defined and used in memprof_allocator.cpp. For now, the memory profile is dumped to text (stderr by default, but honors the sanitizer_common log_path flag). It is dumped in either a default verbose format, or an optional terse format. This patch also adds a set of tests for the core functionality. Differential Revision: https://reviews.llvm.org/D87120 | 5 年前 | |
[MemProf] Memory profiling runtime support See RFC for background: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html Follow on companion to the clang/llvm instrumentation support in D85948 and committed earlier. This patch adds the compiler-rt runtime support for the memory profiling. Note that much of this support was cloned from asan (and then greatly simplified and renamed). For example the interactions with the sanitizer_common allocators, error handling, interception, etc. The bulk of the memory profiling specific code can be found in the MemInfoBlock, MemInfoBlockCache, and related classes defined and used in memprof_allocator.cpp. For now, the memory profile is dumped to text (stderr by default, but honors the sanitizer_common log_path flag). It is dumped in either a default verbose format, or an optional terse format. This patch also adds a set of tests for the core functionality. Differential Revision: https://reviews.llvm.org/D87120 | 5 年前 | |
[NFC][sanitizer] Pass user region into OnMapSecondary | 2 年前 | |
[NFC][sanitizer] Pass user region into OnMapSecondary | 2 年前 | |
sanitizer_common: introduce kInvalidTid/kMainTid Currently we have a bit of a mess related to tids: - sanitizers re-declare kInvalidTid multiple times - some call it kUnknownTid - implicit assumptions that main tid is 0 - asan/memprof claim their tids need to fit into 24 bits, but this does not seem to be true anymore - inconsistent use of u32/int to store tids Introduce kInvalidTid/kMainTid in sanitizer_common and use them consistently. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D101428 | 5 年前 | |
[MemProf] Memory profiling runtime support See RFC for background: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html Follow on companion to the clang/llvm instrumentation support in D85948 and committed earlier. This patch adds the compiler-rt runtime support for the memory profiling. Note that much of this support was cloned from asan (and then greatly simplified and renamed). For example the interactions with the sanitizer_common allocators, error handling, interception, etc. The bulk of the memory profiling specific code can be found in the MemInfoBlock, MemInfoBlockCache, and related classes defined and used in memprof_allocator.cpp. For now, the memory profile is dumped to text (stderr by default, but honors the sanitizer_common log_path flag). It is dumped in either a default verbose format, or an optional terse format. This patch also adds a set of tests for the core functionality. Differential Revision: https://reviews.llvm.org/D87120 | 5 年前 | |
[MemProf] Memory profiling runtime support See RFC for background: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html Follow on companion to the clang/llvm instrumentation support in D85948 and committed earlier. This patch adds the compiler-rt runtime support for the memory profiling. Note that much of this support was cloned from asan (and then greatly simplified and renamed). For example the interactions with the sanitizer_common allocators, error handling, interception, etc. The bulk of the memory profiling specific code can be found in the MemInfoBlock, MemInfoBlockCache, and related classes defined and used in memprof_allocator.cpp. For now, the memory profile is dumped to text (stderr by default, but honors the sanitizer_common log_path flag). It is dumped in either a default verbose format, or an optional terse format. This patch also adds a set of tests for the core functionality. Differential Revision: https://reviews.llvm.org/D87120 | 5 年前 | |
[MemProf] Memory profiling runtime support See RFC for background: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html Follow on companion to the clang/llvm instrumentation support in D85948 and committed earlier. This patch adds the compiler-rt runtime support for the memory profiling. Note that much of this support was cloned from asan (and then greatly simplified and renamed). For example the interactions with the sanitizer_common allocators, error handling, interception, etc. The bulk of the memory profiling specific code can be found in the MemInfoBlock, MemInfoBlockCache, and related classes defined and used in memprof_allocator.cpp. For now, the memory profile is dumped to text (stderr by default, but honors the sanitizer_common log_path flag). It is dumped in either a default verbose format, or an optional terse format. This patch also adds a set of tests for the core functionality. Differential Revision: https://reviews.llvm.org/D87120 | 5 年前 | |
[memprof] Make the raw binary format the default. Set the default memprof serialization format as binary. 9 tests are updated to use print_text=true. Also fixed an issue with concatenation of default and test specified options (missing separator). Differential Revision: https://reviews.llvm.org/D113617 | 4 年前 | |
[MemProf] Memory profiling runtime support See RFC for background: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html Follow on companion to the clang/llvm instrumentation support in D85948 and committed earlier. This patch adds the compiler-rt runtime support for the memory profiling. Note that much of this support was cloned from asan (and then greatly simplified and renamed). For example the interactions with the sanitizer_common allocators, error handling, interception, etc. The bulk of the memory profiling specific code can be found in the MemInfoBlock, MemInfoBlockCache, and related classes defined and used in memprof_allocator.cpp. For now, the memory profile is dumped to text (stderr by default, but honors the sanitizer_common log_path flag). It is dumped in either a default verbose format, or an optional terse format. This patch also adds a set of tests for the core functionality. Differential Revision: https://reviews.llvm.org/D87120 | 5 年前 | |
[compiler-rt] Refactor memintrinsic interceptors This moves memintrinsic interceptors (memcpy/memmove/memset) into a new file sanitizer_common_interceptors_memintrinsics.inc. This is in preparation of redefining builtins, however, we must be careful to not redefine builtins in TUs that define interceptors of the same name. In all cases except for MSan, memintrinsic interceptors were moved to a new TU $tool_interceptors_memintrinsics.cpp. In the case of MSan, it turns out this is not yet necessary (as shown by the later patch introducing memcpy tests). NFC. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D151552 | 3 年前 | |
[compiler-rt] Refactor memintrinsic interceptors This moves memintrinsic interceptors (memcpy/memmove/memset) into a new file sanitizer_common_interceptors_memintrinsics.inc. This is in preparation of redefining builtins, however, we must be careful to not redefine builtins in TUs that define interceptors of the same name. In all cases except for MSan, memintrinsic interceptors were moved to a new TU $tool_interceptors_memintrinsics.cpp. In the case of MSan, it turns out this is not yet necessary (as shown by the later patch introducing memcpy tests). NFC. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D151552 | 3 年前 | |
[compiler-rt] Avoid memintrinsic calls inserted by the compiler D135716 introduced -ftrivial-auto-var-init=pattern where supported. Unfortunately this introduces unwanted memset() for large stack arrays, as shown by the new tests added for asan and msan (tsan already had this test). In general, the problem of compiler-inserted memintrinsic calls (memset/memcpy/memmove) is not new to compiler-rt, and has been a problem before. To avoid introducing unwanted memintrinsic calls, we redefine memintrinsics as __sanitizer_internal_mem* at the assembly level for most source files automatically (where sanitizer_common_internal_defs.h is included). In few cases, redefining a symbol in this way causes issues for interceptors, namely the memintrinsic interceptor themselves. For such source files we have to selectively disable the redefinition. Other alternatives have been considered, but simply do not work well in the context of compiler-rt: 1. Linker --wrap: this does not work because --wrap only applies to the final link, and would not apply when building sanitizer static libraries. 2. Changing references to memset() via objcopy: this may work, but due to the complexities of the build system, introducing such a post-processing step for the right object files (in particular object files defining memset cannot be touched) seems infeasible. The chosen solution works well (as shown by the tests). Other libraries have chosen the same solution where nothing else works (see e.g. glibc's "symbol-hacks.h"). v4: - Add interface attribute to __sanitizer_internal_mem* declarations as well, as otherwise some compilers (MSVC) will complain. - Add SANITIZER_COMMON_NO_REDEFINE_BUILTINS to source files using C++STL, since this could lead to ODR violations (see added comment). v3: - Don't use ALIAS() to alias internal_mem*() functions to __sanitizer_internal_mem*() functions, but just define them as ALWAYS_INLINE functions instead. This will work on darwin and windows. v2: - Fix ubsan_minimal build where compiler decides to insert memset/memcpy: ubsan_minimal has work without RTSanitizerCommonLibc, therefore do not redefine the builtins. - Fix definition of internal_mem* functions with compilers that want the aliased function to already be defined before. - Fix definition of __sanitizer_internal_mem* functions with compilers more pedantic about attribute placement around extern "C". Reviewed By: vitalybuka, dvyukov Differential Revision: https://reviews.llvm.org/D151152 | 3 年前 | |
[compiler-rt] Refactor memintrinsic interceptors This moves memintrinsic interceptors (memcpy/memmove/memset) into a new file sanitizer_common_interceptors_memintrinsics.inc. This is in preparation of redefining builtins, however, we must be careful to not redefine builtins in TUs that define interceptors of the same name. In all cases except for MSan, memintrinsic interceptors were moved to a new TU $tool_interceptors_memintrinsics.cpp. In the case of MSan, it turns out this is not yet necessary (as shown by the later patch introducing memcpy tests). NFC. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D151552 | 3 年前 | |
[MemProf] Add interface to dump profile Add an interface so that the profile can be dumped on demand. Differential Revision: https://reviews.llvm.org/D91768 | 5 年前 | |
[memprof] Simplify initialized flags. As discussed in D145428, the memprof_init_is_running check can be moved to the end of the initialization routine to avoid intercepting allocations during initialization. Also, the memprof_init_done flag can be removed and replaced with memprof_inited. Finally, memprof_inited can also be moved to the end of the method. Tested on the existing check-memprof tests; memprof profile collection succeeded on a large internal workload. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D145528 | 3 年前 | |
[NFC][memprof] Remove unused code | 3 年前 | |
[sanitizer] Switch dlsym hack to internal_allocator Since glibc 2.34, dlsym does 1. malloc 1 2. malloc 2 3. free pointer from malloc 1 4. free pointer from malloc 2 These sequence was not handled by trivial dlsym hack. This fixes https://bugs.llvm.org/show_bug.cgi?id=52278 Reviewed By: eugenis, morehouse Differential Revision: https://reviews.llvm.org/D112588 | 4 年前 | |
[asan][memprof] Declare _DYNAMIC and fix -Wparentheses Declare extern ElfW(Dyn) _DYNAMIC[]; so that it will trivially work on musl. | 5 年前 | |
[memprof] Move the meminfo block struct to MemProfData.inc. The definition of the MemInfoBlock is shared between the memprof compiler-rt runtime and llvm/lib/ProfileData/. This change removes the memprof_meminfoblock header and moves the struct to the shared include file. To enable this sharing, the Print method is moved to the memprof_allocator (the only place it is used) and the remaining uses are updated to refer to the MemInfoBlock defined in the MemProfData.inc file. Also a couple of other minor changes which improve usability of the types in MemProfData.inc. * Update the PACKED macro to handle commas. * Add constructors and equality operators. * Don't initialize the buildid field. Differential Revision: https://reviews.llvm.org/D116780 | 4 年前 | |
[memprof] Move the meminfo block struct to MemProfData.inc. The definition of the MemInfoBlock is shared between the memprof compiler-rt runtime and llvm/lib/ProfileData/. This change removes the memprof_meminfoblock header and moves the struct to the shared include file. To enable this sharing, the Print method is moved to the memprof_allocator (the only place it is used) and the remaining uses are updated to refer to the MemInfoBlock defined in the MemProfData.inc file. Also a couple of other minor changes which improve usability of the types in MemProfData.inc. * Update the PACKED macro to handle commas. * Add constructors and equality operators. * Don't initialize the buildid field. Differential Revision: https://reviews.llvm.org/D116780 | 4 年前 | |
[MemProf] Memory profiling runtime support See RFC for background: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html Follow on companion to the clang/llvm instrumentation support in D85948 and committed earlier. This patch adds the compiler-rt runtime support for the memory profiling. Note that much of this support was cloned from asan (and then greatly simplified and renamed). For example the interactions with the sanitizer_common allocators, error handling, interception, etc. The bulk of the memory profiling specific code can be found in the MemInfoBlock, MemInfoBlockCache, and related classes defined and used in memprof_allocator.cpp. For now, the memory profile is dumped to text (stderr by default, but honors the sanitizer_common log_path flag). It is dumped in either a default verbose format, or an optional terse format. This patch also adds a set of tests for the core functionality. Differential Revision: https://reviews.llvm.org/D87120 | 5 年前 | |
[MemProf] Memory profiling runtime support See RFC for background: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html Follow on companion to the clang/llvm instrumentation support in D85948 and committed earlier. This patch adds the compiler-rt runtime support for the memory profiling. Note that much of this support was cloned from asan (and then greatly simplified and renamed). For example the interactions with the sanitizer_common allocators, error handling, interception, etc. The bulk of the memory profiling specific code can be found in the MemInfoBlock, MemInfoBlockCache, and related classes defined and used in memprof_allocator.cpp. For now, the memory profile is dumped to text (stderr by default, but honors the sanitizer_common log_path flag). It is dumped in either a default verbose format, or an optional terse format. This patch also adds a set of tests for the core functionality. Differential Revision: https://reviews.llvm.org/D87120 | 5 年前 | |
[MemProf] Memory profiling runtime support See RFC for background: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html Follow on companion to the clang/llvm instrumentation support in D85948 and committed earlier. This patch adds the compiler-rt runtime support for the memory profiling. Note that much of this support was cloned from asan (and then greatly simplified and renamed). For example the interactions with the sanitizer_common allocators, error handling, interception, etc. The bulk of the memory profiling specific code can be found in the MemInfoBlock, MemInfoBlockCache, and related classes defined and used in memprof_allocator.cpp. For now, the memory profile is dumped to text (stderr by default, but honors the sanitizer_common log_path flag). It is dumped in either a default verbose format, or an optional terse format. This patch also adds a set of tests for the core functionality. Differential Revision: https://reviews.llvm.org/D87120 | 5 年前 | |
[NFC][sanitizer] Move ArrayRef into own header | 3 年前 | |
[NFC][sanitizer] Move ArrayRef into own header | 3 年前 | |
[memprof] Simplify initialized flags. As discussed in D145428, the memprof_init_is_running check can be moved to the end of the initialization routine to avoid intercepting allocations during initialization. Also, the memprof_init_done flag can be removed and replaced with memprof_inited. Finally, memprof_inited can also be moved to the end of the method. Tested on the existing check-memprof tests; memprof profile collection succeeded on a large internal workload. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D145528 | 3 年前 | |
[MemProf] Memory profiling runtime support See RFC for background: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html Follow on companion to the clang/llvm instrumentation support in D85948 and committed earlier. This patch adds the compiler-rt runtime support for the memory profiling. Note that much of this support was cloned from asan (and then greatly simplified and renamed). For example the interactions with the sanitizer_common allocators, error handling, interception, etc. The bulk of the memory profiling specific code can be found in the MemInfoBlock, MemInfoBlockCache, and related classes defined and used in memprof_allocator.cpp. For now, the memory profile is dumped to text (stderr by default, but honors the sanitizer_common log_path flag). It is dumped in either a default verbose format, or an optional terse format. This patch also adds a set of tests for the core functionality. Differential Revision: https://reviews.llvm.org/D87120 | 5 年前 | |
[MemProf] Memory profiling runtime support See RFC for background: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html Follow on companion to the clang/llvm instrumentation support in D85948 and committed earlier. This patch adds the compiler-rt runtime support for the memory profiling. Note that much of this support was cloned from asan (and then greatly simplified and renamed). For example the interactions with the sanitizer_common allocators, error handling, interception, etc. The bulk of the memory profiling specific code can be found in the MemInfoBlock, MemInfoBlockCache, and related classes defined and used in memprof_allocator.cpp. For now, the memory profile is dumped to text (stderr by default, but honors the sanitizer_common log_path flag). It is dumped in either a default verbose format, or an optional terse format. This patch also adds a set of tests for the core functionality. Differential Revision: https://reviews.llvm.org/D87120 | 5 年前 | |
sanitizer_common: deduplicate CheckFailed We have some significant amount of duplication around CheckFailed functionality. Each sanitizer copy-pasted a chunk of code. Some got random improvements like dealing with recursive failures better. These improvements could benefit all sanitizers, but they don't. Deduplicate CheckFailed logic across sanitizers and let each sanitizer only print the current stack trace. I've tried to dedup stack printing as well, but this got me into cmake hell. So let's keep this part duplicated in each sanitizer for now. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D102221 | 5 年前 | |
[NFC][sanitizer] Return StackDepotStats by value Differential Revision: https://reviews.llvm.org/D110644 | 4 年前 | |
[MemProf] Memory profiling runtime support See RFC for background: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html Follow on companion to the clang/llvm instrumentation support in D85948 and committed earlier. This patch adds the compiler-rt runtime support for the memory profiling. Note that much of this support was cloned from asan (and then greatly simplified and renamed). For example the interactions with the sanitizer_common allocators, error handling, interception, etc. The bulk of the memory profiling specific code can be found in the MemInfoBlock, MemInfoBlockCache, and related classes defined and used in memprof_allocator.cpp. For now, the memory profile is dumped to text (stderr by default, but honors the sanitizer_common log_path flag). It is dumped in either a default verbose format, or an optional terse format. This patch also adds a set of tests for the core functionality. Differential Revision: https://reviews.llvm.org/D87120 | 5 年前 | |
memprof: don't use thread user_id memprof does not use user_id for anything, so don't pass it to ThreadCreate. Passing a random field of MemprofThread as user_id does not make much sense anyway. Depends on D113920. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D113921 | 4 年前 | |
sanitizer_common: add simpler ThreadRegistry ctor Currently ThreadRegistry is overcomplicated because of tsan, it needs tid quarantine and reuse counters. Other sanitizers don't need that. It also seems that no other sanitizer now needs max number of threads. Asan used to need 2^24 limit, but it does not seem to be needed now. Other sanitizers blindly copy-pasted that without reasons. Lsan also uses quarantine, but I don't see why that may be potentially needed. Add a ThreadRegistry ctor that does not require any sizes and use it in all sanitizers except for tsan. In preparation for new tsan runtime, which won't need any of these parameters as well. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D105713 | 4 年前 | |
[MemProf] Allow the binary to specify the profile output filename This will allow the output directory to be specified by a build time option, similar to the directory specified for regular PGO profiles via -fprofile-generate=. The memory profiling instrumentation pass will set up the variable. This is the same mechanism used by the PGO instrumentation and runtime. Depends on D87120 and D89629. Differential Revision: https://reviews.llvm.org/D89086 | 5 年前 |
MemProfiling RT
This directory contains sources of the MemProfiling (MemProf) runtime library.
Directory structure: README.txt : This file. CMakeLists.txt : File for cmake-based build. memprof_*.{cc,h} : Sources of the memprof runtime library.
Also MemProf runtime needs the following libraries: lib/interception/ : Machinery used to intercept function calls. lib/sanitizer_common/ : Code shared between various sanitizers.
MemProf runtime can only be built by CMake. You can run MemProf tests from the root of your CMake build tree:
make check-memprof