VVitaly Buka[NFC][memprof] Remove unused code
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[compiler-rt][CMake] Set --unwindlib=none when using LLVM libunwind We already link libunwind explicitly so avoid trying to link toolchain's default libunwind which may be missing. This matches what we already do for libcxx and libcxxabi. Differential Revision: https://reviews.llvm.org/D129472 | 3 年前 | |
[memprof] Extend llvm-profdata to display MemProf profile summaries. This commit adds initial support to llvm-profdata to read and print summaries of raw memprof profiles. Summary of changes: * Refactor shared defs to MemProfData.inc * Extend show_main to display memprof profile summaries. * Add a simple raw memprof profile reader. * Add a couple of tests to tools/llvm-profdata. Differential Revision: https://reviews.llvm.org/D114286 | 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 年前 | |
[NFC][sanitizer] Consolidate malloc hook invocations | 4 年前 | |
[NFC][sanitizer] Remove SetSoftRssLimitExceededCallback According comments on D44404, something like that was the goal. Reviewed By: morehouse, kstoimenov Differential Revision: https://reviews.llvm.org/D114991 | 4 年前 | |
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 年前 | |
tsan: fix false positives in dynamic libs with static tls The added test demonstrates loading a dynamic library with static TLS. Such static TLS is a hack that allows a dynamic library to have faster TLS, but it can be loaded only iff all threads happened to allocate some excess of static TLS space for whatever reason. If it's not the case loading fails with: dlopen: cannot load any more object with static TLS We used to produce a false positive because dlopen will write into TLS of all existing threads to initialize/zero TLS region for the loaded library. And this appears to be racing with initialization of TLS in the thread since we model a write into the whole static TLS region (we don't what part of it is currently unused): WARNING: ThreadSanitizer: data race (pid=2317365) Write of size 1 at 0x7f1fa9bfcdd7 by main thread: 0 memset 1 init_one_static_tls 2 __pthread_init_static_tls [[ this is where main calls dlopen ]] 3 main Previous write of size 8 at 0x7f1fa9bfcdd0 by thread T1: 0 __tsan_tls_initialization Fix this by ignoring accesses during dlopen. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D114953 | 4 年前 | |
[sanitizer] Fix VReport of symbol version Version is already a string and does not need stringizing. | 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] 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 年前 | |
[NFC][memprof] Remove unused code | 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 年前 | |
[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] Extend llvm-profdata to display MemProf profile summaries. This commit adds initial support to llvm-profdata to read and print summaries of raw memprof profiles. Summary of changes: * Refactor shared defs to MemProfData.inc * Extend show_main to display memprof profile summaries. * Add a simple raw memprof profile reader. * Add a couple of tests to tools/llvm-profdata. Differential Revision: https://reviews.llvm.org/D114286 | 4 年前 | |
[Sanitizer][Darwin] Cleanup MaybeReexec() function and usage While investigating another issue, I noticed that MaybeReexec() never actually "re-executes via execv()" anymore. DyldNeedsEnvVariable() only returned true on macOS 10.10 and below. Usually, I try to avoid "unnecessary" cleanups (it's hard to be certain that there truly is no fallout), but I decided to do this one because: * I initially tricked myself into thinking that MaybeReexec() was relevant to my original investigation (instead of being dead code). * The deleted code itself is quite complicated. * Over time a few other things were mushed into MaybeReexec(): initializing MonotonicNanoTime(), verifying interceptors are working, and stripping the DYLD_INSERT_LIBRARIES env var to avoid problems when forking. * This platform-specific thing leaked into sanitizer_common.h. * The ReexecDisabled() config nob relies on the "strong overrides weak pattern", which is now problematic and can be completely removed. * ReexecDisabled() actually hid another issue with interceptors not working in unit tests. I added an explicit verify_interceptors (defaults to true) option instead. Differential Revision: https://reviews.llvm.org/D129157 | 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