14 Commits

Author SHA1 Message Date
Jake Egan
8e072b9d49
[sanitizer_common][nfc] Rename tid_t to avoid conflicting declarations (#149011)
`tid_t` is also defined in the AIX header `/usr/include/sys/types.h`
which is included by system `pthread.h`. The use of `tid_t` by AIX is
conforming according to
[POSIX](https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html):
> Implementations may add symbols to the headers shown in the following
table [ ... ]
2025-07-23 09:39:19 -04:00
Vitaly Buka
abe148a09f
[NFC][sanitizer][asan] Promote stack_id into ThreadContextBase (#111917)
`parent_id` and `stack_id` represent location
where the thread was created, so it's reasonable
to keep them togeter.

For now, only Asan and MemProf use `stack_id`,
but it will be halpfull to print thread origin from
other sanitizers as well.

For #111948
2024-10-11 14:47:01 -07:00
Vitaly Buka
f13b7d0b02
Reland "[sanitizer] Fix partially initialized static TLS range" (#108883)
Reland llvm/llvm-project#108685

Arguments order was wrong on Windows and Darwin.
2024-09-16 14:05:00 -07:00
Vitaly Buka
9a1d0744ed
Revert "[sanitizer] Fix partially initialized static TLS range" (#108881)
Reverts llvm/llvm-project#108685

Breaks Darwin and Windows
https://lab.llvm.org/buildbot/#/builders/107/builds/2930
https://ci.swift.org/view/all/job/llvm.org/view/LLDB/job/as-lldb-cmake/11684/
2024-09-16 13:51:23 -07:00
Vitaly Buka
b7c9ebe4ec
[sanitizer] Fix partially initialized static TLS range (#108685)
Fixes asan, msan crash on check added in #108684.
The #108684 includes reproducer of the issue.

Change interface of `GetThreadStackAndTls` to
set `tls_begin` and `tls_end` at the same time.
2024-09-16 12:48:24 -07:00
Fangrui Song
ba66d60b1c
[sanitizer] Replace ALIGNED with alignas
C++11 `alignas` is already used extensively. `alignas` must precede
`static`, so adjust the ordering accordingly.

msan.cpp: Clang 15 doesn't allow `__attribute__((visibility("default"))) alignas(16)`.
Use the order `alignas(16) SANITIZER_INTERFACE_ATTRIBUTE`. Tested with Clang 7.

Pull Request: https://github.com/llvm/llvm-project/pull/98958
2024-07-15 16:12:42 -07:00
Dmitry Vyukov
d1f72f02d0 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
2021-11-17 14:49:25 +01:00
Martin Liska
13a442ca49 Enable -Wformat-pedantic and fix fallout.
Differential Revision: https://reviews.llvm.org/D113172
2021-11-05 13:12:35 +01:00
Dmitry Vyukov
56debbf52e sanitizers: switch BlockingMutex(LINKER_INITIALIZED) to Mutex
Mutex does not support LINKER_INITIALIZED support.
As preparation to switching BlockingMutex to Mutex,
proactively replace all BlockingMutex(LINKER_INITIALIZED) to Mutex.
All of these are objects with static storage duration and Mutex ctor
is constexpr, so it should be equivalent.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D106944
2021-07-28 15:09:34 +02:00
Dmitry Vyukov
dfd9808b6c 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
2021-07-13 22:52:25 -07:00
Vitaly Buka
b4a6fa12d1 Revert "sanitizer_common: add simpler ThreadRegistry ctor"
Breaks https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-android

This reverts commit 6062c672bc5e560a4c3dc73741f9e82b39d08527.
This reverts commit 8e489b4b96e31cfb004e03cfa1393c425c504013.
2021-07-12 12:04:12 -07:00
Dmitry Vyukov
8e489b4b96 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
2021-07-11 12:36:28 +02:00
Dmitry Vyukov
92a3a2dc3e 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
2021-04-30 15:58:05 +02:00
Teresa Johnson
3d4bba302d [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
2020-10-16 09:47:02 -07:00