|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
| #
ca50840b |
| 01-Jul-2022 |
Julian Lettner <[email protected]> |
[Sanitizer][Darwin] Cleanup MaybeReexec() function and usage
While investigating another issue, I noticed that `MaybeReexec()` never actually "re-executes via `execv()`" anymore. `DyldNeedsEnvVaria
[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
show more ...
|
| #
7789c9af |
| 08-Jul-2022 |
Julian Lettner <[email protected]> |
Revert "[Sanitizer][Darwin] Cleanup MaybeReexec() function and usage"
Many tests for the `UBSan-Standalone-iossim-x86_64` fail with this. Reverting so I can investigate.
This reverts commit 0a9667b
Revert "[Sanitizer][Darwin] Cleanup MaybeReexec() function and usage"
Many tests for the `UBSan-Standalone-iossim-x86_64` fail with this. Reverting so I can investigate.
This reverts commit 0a9667b0f56b1b450abd02f74c6175bea54f832e.
show more ...
|
| #
0a9667b0 |
| 01-Jul-2022 |
Julian Lettner <[email protected]> |
[Sanitizer][Darwin] Cleanup MaybeReexec() function and usage
While investigating another issue, I noticed that `MaybeReexec()` never actually "re-executes via `execv()`" anymore. `DyldNeedsEnvVaria
[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
show more ...
|
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
| #
d49aaaf4 |
| 11-Feb-2022 |
Florian Mayer <[email protected]> |
[memprof] Fix UB.
An infinite loop without any effects is illegal C++ and can be optimized away by the compiler.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D119575
|
| #
11b0506c |
| 11-Feb-2022 |
Florian Mayer <[email protected]> |
[Sanitizers] Fix build broken by missing import.
|
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
| #
63180012 |
| 02-Dec-2021 |
Vitaly Buka <[email protected]> |
[sanitizer] Support IsRssLimitExceeded in all sanitizers
Reviewed By: kstoimenov
Differential Revision: https://reviews.llvm.org/D115000
|
| #
36e6a259 |
| 02-Dec-2021 |
Vitaly Buka <[email protected]> |
[NFC][sanitizer] Remove SetSoftRssLimitExceededCallback
According comments on D44404, something like that was the goal.
Reviewed By: morehouse, kstoimenov
Differential Revision: https://reviews.ll
[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
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc1 |
|
| #
0d8bdc17 |
| 30-Sep-2021 |
Teresa Johnson <[email protected]> |
[MemProf] Record accesses for all words touched in mem intrinsic
Previously for mem* intrinsics we only incremented the access count for the first word in the range. However, after thinking it throu
[MemProf] Record accesses for all words touched in mem intrinsic
Previously for mem* intrinsics we only incremented the access count for the first word in the range. However, after thinking it through I think it makes more sense to record an access for every word in the range. This better matches the behavior of inlined memory intrinsics, and also allows better analysis of utilization at a future date.
Differential Revision: https://reviews.llvm.org/D110799
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
| #
2721e27c |
| 11-May-2021 |
Dmitry Vyukov <[email protected]> |
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 li
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
show more ...
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5 |
|
| #
0e92cbd6 |
| 05-Apr-2021 |
Nico Weber <[email protected]> |
Revert "[sanitizer] Simplify GetTls with dl_iterate_phdr on Linux"
This reverts commit ec575e3b0a462ff7a3d23d0f39a22147606050de. Still doesn't work, see https://crbug.com/1196037
|
| #
ec575e3b |
| 04-Apr-2021 |
Fangrui Song <[email protected]> |
[sanitizer] Simplify GetTls with dl_iterate_phdr on Linux
This was reverted by f176803ef1f4050a350e01868d64fe09a674d3bf due to Ubuntu 16.04 x86-64 glibc 2.23 problems. This commit additionally calls
[sanitizer] Simplify GetTls with dl_iterate_phdr on Linux
This was reverted by f176803ef1f4050a350e01868d64fe09a674d3bf due to Ubuntu 16.04 x86-64 glibc 2.23 problems. This commit additionally calls `__tls_get_addr({modid,0})` to work around the dlpi_tls_data==NULL issues for glibc<2.25 (https://sourceware.org/bugzilla/show_bug.cgi?id=19826)
GetTls is the range of
* thread control block and optional TLS_PRE_TCB_SIZE * static TLS blocks plus static TLS surplus
On glibc, lsan requires the range to include `pthread::{specific_1stblock,specific}` so that allocations only referenced by `pthread_setspecific` can be scanned.
This patch uses `dl_iterate_phdr` to collect TLS blocks. Find the one with `dlpi_tls_modid==1` as one of the initially loaded module, then find consecutive ranges. The boundaries give us addr and size.
This allows us to drop the glibc internal `_dl_get_tls_static_info` and `InitTlsSize` entirely. Use the simplified method with non-Android Linux for now, but in theory this can be used with *BSD and potentially other ELF OSes.
This simplification enables D99566 for TLS Variant I architectures.
See https://reviews.llvm.org/D93972#2480556 for analysis on GetTls usage across various sanitizers.
Differential Revision: https://reviews.llvm.org/D98926
show more ...
|
| #
f176803e |
| 02-Apr-2021 |
Nico Weber <[email protected]> |
Revert "[sanitizer] Simplify GetTls with dl_iterate_phdr"
This reverts commit 9be8f8b34d9b150cd1811e3556fe9d0cd735ae29. This breaks tsan on Ubuntu 16.04:
$ cat tiny_race.c #include <pthread
Revert "[sanitizer] Simplify GetTls with dl_iterate_phdr"
This reverts commit 9be8f8b34d9b150cd1811e3556fe9d0cd735ae29. This breaks tsan on Ubuntu 16.04:
$ cat tiny_race.c #include <pthread.h> int Global; void *Thread1(void *x) { Global = 42; return x; } int main() { pthread_t t; pthread_create(&t, NULL, Thread1, NULL); Global = 43; pthread_join(t, NULL); return Global; } $ out/gn/bin/clang -fsanitize=thread -g -O1 tiny_race.c --sysroot ~/src/chrome/src/build/linux/debian_sid_amd64-sysroot/ $ docker run -v $PWD:/foo ubuntu:xenial /foo/a.out FATAL: ThreadSanitizer CHECK failed: ../../compiler-rt/lib/tsan/rtl/tsan_platform_linux.cpp:447 "((thr_beg)) >= ((tls_addr))" (0x7fddd76beb80, 0xfffffffffffff980) #0 <null> <null> (a.out+0x4960b6) #1 <null> <null> (a.out+0x4b677f) #2 <null> <null> (a.out+0x49cf94) #3 <null> <null> (a.out+0x499bd2) #4 <null> <null> (a.out+0x42aaf1) #5 <null> <null> (libpthread.so.0+0x76b9) #6 <null> <null> (libc.so.6+0x1074dc)
(Get the sysroot from here: https://commondatastorage.googleapis.com/chrome-linux-sysroot/toolchain/500976182686961e34974ea7bdc0a21fca32be06/debian_sid_amd64_sysroot.tar.xz)
Also reverts follow-on commits: This reverts commit 58c62fd9768594ec8dd57e8320ba2396bf8b87e5. This reverts commit 31e541e37587100a5b21378380f54c028fda2d04.
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc4 |
|
| #
9be8f8b3 |
| 26-Mar-2021 |
Fangrui Song <[email protected]> |
[sanitizer] Simplify GetTls with dl_iterate_phdr
GetTls is the range of
* thread control block and optional TLS_PRE_TCB_SIZE * static TLS blocks plus static TLS surplus
On glibc, lsan requires the
[sanitizer] Simplify GetTls with dl_iterate_phdr
GetTls is the range of
* thread control block and optional TLS_PRE_TCB_SIZE * static TLS blocks plus static TLS surplus
On glibc, lsan requires the range to include `pthread::{specific_1stblock,specific}` so that allocations only referenced by `pthread_setspecific` can be scanned.
This patch uses `dl_iterate_phdr` to collect TLS ranges. Find the one with `dlpi_tls_modid==1` as one of the initially loaded module, then find consecutive ranges. The boundaries give us addr and size.
This allows us to drop the glibc internal `_dl_get_tls_static_info` and `InitTlsSize` entirely. Use the simplified method with non-Android Linux for now, but in theory this can be used with *BSD and potentially other ELF OSes.
In the future, we can move `ThreadDescriptorSize` code to lsan (and consider intercepting `pthread_setspecific`) to avoid hacks in generic code.
See https://reviews.llvm.org/D93972#2480556 for analysis on GetTls usage across various sanitizers.
Differential Revision: https://reviews.llvm.org/D98926
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2 |
|
| #
d7e71b5d |
| 08-Dec-2020 |
Jeroen Dobbelaere <[email protected]> |
[compiler-rt santizer] Use clock_gettime instead of timespec_get
On RH66, timespec_get is not available. Use clock_gettime instead.
This problem was introduced with D87120
Reviewed By: tejohnson
[compiler-rt santizer] Use clock_gettime instead of timespec_get
On RH66, timespec_get is not available. Use clock_gettime instead.
This problem was introduced with D87120
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D91687
show more ...
|
|
Revision tags: llvmorg-11.0.1-rc1 |
|
| #
ed4fbe6d |
| 30-Oct-2020 |
Petr Hosek <[email protected]> |
[CMake] Replace ctime with time.h in memprof
Part of D88922
|
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5 |
|
| #
5c20d7db |
| 29-Sep-2020 |
Teresa Johnson <[email protected]> |
[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 prof
[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
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3 |
|
| #
3d4bba30 |
| 03-Sep-2020 |
Teresa Johnson <[email protected]> |
[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 D8
[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
show more ...
|