History log of /llvm-project-15.0.7/compiler-rt/lib/memprof/memprof_rtl.cpp (Results 1 – 17 of 17)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...