Currently we only support %z and %ll width modifiers,
but surprisingly not %l. This makes it impossible to print longs
(sizeof(long) not necessary equal to sizeof(size_t)).
We had some printf's that printed longs with %zu,
but that's wrong and now with __attribute__((format)) in place
they are flagged by compiler. So we either have a choice of
doing static_cast<uptr>(long) everywhere or add %l.
Adding %l looks better, that's a standard modifier.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108066
No point in declaring variables separately before use.
Depends on D107979.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108015
This reverts commits
"sanitizer_common: support printing __m128i type"
and "[sanitizer] Fix VSNPrintf %V on Windows".
Unfortunately, custom "%V" is inherently incompatible with -Wformat,
it produces both:
warning: invalid conversion specifier 'V' [-Wformat-invalid-specifier]
warning: data argument not used by format string [-Wformat-extra-args]
If we disable both of these warnings we lose lots of useful warnings as well.
Depends on D107978.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107979
The __attribute__((format)) was added somewhere in 2012,
the lost during refactoring, then re-added in 2014 but
to te source files, which is a no-op.
Move it back to header files so that it actually takes effect.
But over the past 7 years we've accumulated whole lot of
format string bugs of different types, so disable the warning
with -Wno-format for now for incremental clean up.
Among the bugs that it warns about are all kinds of bad things:
- wrong sizes of arguments
- missing/excessive arguments
- printing wrong things (e.g. *ptr instead of ptr)
- completely messed up format strings
- security issues where external string is used as format
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107977
Add FALLTHROUGH portably defined to [[clang::fallthrough]].
We have -Wimplicit-fallthrough already enabled, and currently
it's not possible to fix the warning.
Depends on D107735.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107736
After switching tsan from the old mutex to the new sanitizer_common mutex,
we've observed a significant degradation of performance on a test.
The test effectively stresses a lock-free stack with 4 threads
with a mix of atomic_compare_exchange and atomic_load operations.
The former takes write lock, while the latter takes read lock.
It turned out the new mutex performs worse because readers don't
use active spinning, which results in significant amount of thread
blocking/unblocking. The old tsan mutex used active spinning
for both writers and readers.
Add active spinning for readers.
Don't hand off the mutex to readers, and instread make them
compete for the mutex after wake up again.
This makes readers and writers almost symmetric.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107824
tsan in some cases (e.g. after fork from multithreaded program, which arguably is problematic) increments ignore_interceptors and in that case runs just the intercepted functions and not their wrappers.
For realpath the interceptor handles the resolved_path == nullptr case though and so when ignore_interceptors is non-zero, realpath (".", nullptr) will fail instead of succeeding.
This patch uses instead the COMMON_INTERCEPT_FUNCTION_GLIBC_VER_MIN macro to use realpath@@GLIBC_2.3 whenever possible (if not, then it is likely a glibc architecture
with more recent oldest symbol version than 2.3, for which any realpath in glibc will DTRT, or unsupported glibc older than 2.3), which never supported NULL as second argument.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D107819
022439931f added code that is only enabled
when COMPILER_RT_DEBUG is enabled. This code doesn't build on targets
that don't support thread local storage because the code added uses the
THREADLOCAL macro. Consequently the COMPILER_RT_DEBUG build broke for
some Apple targets (e.g. 32-bit iOS simulators).
```
/Volumes/user_data/dev/llvm/llvm.org/main/src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_mutex.cpp:216:8: error: thread-local storage is not supported for the current target
static THREADLOCAL InternalDeadlockDetector deadlock_detector;
^
/Volumes/user_data/dev/llvm/llvm.org/main/src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:227:24: note: expanded from macro 'THREADLOCAL'
# define THREADLOCAL __thread
^
1 error generated.
```
To fix this, this patch introduces a `SANITIZER_SUPPORTS_THREADLOCAL`
macro that is `1` iff thread local storage is supported by the current
target. That condition is then added to `SANITIZER_CHECK_DEADLOCKS` to
ensure the code is only enabled when thread local storage is available.
The implementation of `SANITIZER_SUPPORTS_THREADLOCAL` currently assumes
Clang. See `llvm-project/clang/include/clang/Basic/Features.def` for the
definition of the `tls` feature.
rdar://81543007
Differential Revision: https://reviews.llvm.org/D107524
Similar to qsort, bsearch can be called from non-instrumented
code of glibc. When it happends tls for arguments can be in uninitialized
state.
Unlike to qsort, bsearch does not move data, so we don't need to
check or initialize searched memory or key. Intrumented comparator will
do that on it's own.
Differential Revision: https://reviews.llvm.org/D107387
Don't lock the sync object inside of MetaMap methods.
This has several advantages:
- the new interface does not confuse thread-safety analysis
so we can remove a bunch of NO_THREAD_SAFETY_ANALYSIS attributes
- this allows use of scoped lock objects
- this allows more flexibility, e.g. locking some other mutex
between searching and locking the sync object
Also prefix the methods with GetSync to be consistent with GetBlock method.
Also make interface wrappers inlinable, otherwise we either end up with
2 copies of the method, or with an additional call.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107256
Currently we inconsistently use u32 and int for thread ids,
there are also "unique tid" and "os tid" and just lots of other
things identified by integers.
Additionally new tsan runtime will introduce yet another
thread identifier that is very different from current tids.
Similarly for stack IDs, it's easy to confuse u32 with other
integer identifiers. And when a function accepts u32 or a struct
contains u32 field, it's not always clear what it is.
Add Tid and StackID typedefs to make it clear what is what.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107152
As code diverge from Google style we need
to add more and more exceptions to suppress
conflicts with clang-format and clang-tidy.
As this point it does not provide a additional value.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D107197
Rather than throwing an error. This way we can still use files like
hwasan_dynamic_shadow.cpp for other platforms without leading to a
preprocessor error.
Differential Revision: https://reviews.llvm.org/D106979
Compilers tends to insert memset/memcpy for some struct/array operations,
and these don't play well inside of sanitizer runtimes.
Avoiding these calls was the intention behind internal_memset.
Remove the leftover ={} that can result in memset call.
Reviewed By: vitalybuka, pgousseau
Differential Revision: https://reviews.llvm.org/D106978
Mutex supports reader access, OS blocking, spinning,
portable and smaller than BlockingMutex.
Overall it's supposed to be better than RWMutex/BlockingMutex.
Replace RWMutex/BlockingMutex with Mutex.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D106936
Mutex does not support LINKER_INITIALIZED ctor.
But we used to support it with BlockingMutex.
To prevent potential bugs delete LINKER_INITIALIZED Mutex ctor.
Also mark existing ctor as explicit.
Depends on D106944.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D106945
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
This reverts commit 1e1f752027.
It breaks ignore_noninstrumented_modules=1.
Somehow we did not have any portable tests for this mode before
(only Darwin tests). Add a portable test as well.
Moreover, I think I was too fast uninlining all LibIgnore checks.
For Java, Darwin and OpenMP LibIgnore is always enabled,
so it makes sense to leave it as it was before.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D106855
Ensure that libSupport does not carry any static global initializer.
libSupport can be embedded in use cases where we don't want to load all
cl::opt unless we want to parse the command line.
ManagedStatic can be used to enable lazy-initialization of globals.
The -Werror=global-constructors is only added on platform that have
support for the flag and for which std::mutex does not have a global
destructor. This is ensured by having CMake trying to compile a file
with a global mutex before adding the flag to libSupport.
Now that sanitizer_common mutex has feature-parity with tsan mutex,
switch tsan to the sanitizer_common mutex and remove tsan's custom mutex.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D106379
Copy internal deadlock detector from tsan to sanitizer_common
(with some cosmetic changes).
Tsan version will be deleted in subsequent changes.
This allows us to switch tsan to the sanitizer_common mutex
and remove tsan's mutex.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D106546
The current (default) line length is 80 columns.
That's based on old hardware and historical conventions.
There are no existent reasons to keep line length that small,
especially provided that our coding style uses quite lengthy
identifiers. The Linux kernel recently switched to 100,
let's start with 100 as well.
This change intentionally does not re-format code.
Re-formatting is intended to happen incrementally,
or on dir-by-dir basis separately.
Reviewed By: vitalybuka, melver, MaskRay
Differential Revision: https://reviews.llvm.org/D106436
Vitaly Buka