This patch adds static keyword to internal functions that write
binary id to restrict visibility to the file that they are declared.
Differential Revision: https://reviews.llvm.org/D108154
`scudo::uptr` was defined as an `unsigned long` on 32-b platform,
while a `uintptr_t` is usually defined as an `unsigned int`.
This worked, this was not consistent, particularly with regard to
format string specifiers.
As suggested by Vitaly, since we are including `stdint.h`, define
the internal `scudo` integer types to those.
Differential Revision: https://reviews.llvm.org/D108089
At least when compiling with gcc, this is not supported and will
result in errors when linking against the profiler runtime. Only
use the pragma comment linker based code with MSVC, but not with
a mingw toolchain. This also undoes D107620, which shouldn't be
relevant anymore.
Differential Revision: https://reviews.llvm.org/D108095
Add structures for the new trace format,
functions that serialize and add events to the trace
and trace replaying logic.
Differential Revision: https://reviews.llvm.org/D107911
Tsan's check_memcpy.c test was disabled under debug because it failed.
But it points to real issues and does not help to just disable it.
I tried to enable it and see what fail and the first hit was default ctor for:
struct ChainedOriginDepotDesc {
u32 here_id;
u32 prev_id;
};
initializing these fields to 0's help partially,
but compiler still emits memset before calling ctor.
I did not try to see what's the next failure, because if it fails
on such small structs, it won't be realistic to fix everything
and keep working.
Compile runtimes with -O1 under debug instead.
It seems to fix all current failures. At least I run check-tsan
under clang/gcc x debug/non-debug and all combinations passed.
-O1 does not usually use too aggressive optimizations
and sometimes even makes debugging easier because machine code
is not exceedingly verbose.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107962
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
We use kShadowCnt (number of shadow cells per application granule)
when computing shadow, but it's wrong. We need the ratio
between shadow and app memory (how much shadow is larger than app memory),
which is kShadowMultiplier.
Currently both are equal to 4, so it works fine.
Use the correct constant.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D108033
Move __attribute__((format)) to the function declarations in the header file.
It's almost pointless in the source file.
But disable the warning with -Wno-format for now
since there is a number of existing warnings.
Depends on D107984.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108014
This fixes just a few of the warnings.
Ubsan is not completely clean yet,
but these somehow pop up while I was
fixing other sanitizers.
Depends on D107983.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107984
Enable -Wformat in sanitizer_common now that it's
cleaned up from existing warnings.
But disable it in all sanitizers for now since
they are not cleaned up yet, but inherit sanitizer_common CFLAGS.
Depends on D107980.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107981
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 should be in the header on declaration.
It's almost pointless in the source file.
Depends on D107977.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107978
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
New ports in glibc typically don't define ELF_INITFINI, so
DT_INIT/DT_FINI support is disabled.
(rhel ppc64le likely patches their glibc this way as well.)
musl can disable DT_INIT/DT_FINI via -DNO_LEGACY_INITFINI.
So we cannot guarantee ctor()/dtor() will be printed.
The default compiler-generated MutexSet::Desc::operator=()
now contains memcpy() call since Desc become bigger.
This fails in debug mode since we call interceptor from within the runtime.
Define own operator=() using internal_memcpy().
This also makes copy ctor necessary, otherwise:
tsan_mutexset.h:33:11: warning: definition of implicit copy constructor for
'Desc' is deprecated because it has a user-declared copy assignment operator
And if we add copy ctor, we also need the default ctor
since it's called by MutexSet ctor.
Depends on D107911.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107959
We currently memorize u64 id + epoch for each mutex.
The new tsan runtime will memorize address + stack_id instead.
But switching to address + stack_id requires new trace,
which in turn requires new MutexSet and some other changes.
Extend MutexSet to support both new and old info to break
the dependency cycles. The plan is to remove the old
info/methods after switching to the new runtime.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D107910
AppMemBeg was renamed to LoAppMemBeg in 3830c93478
("tsan: rename kAppMemBeg to kLoAppMemBeg").
Rename remaining uses of the old name in tsan_platform_mac.cpp.
Differential Revision: https://reviews.llvm.org/D107948
Provide accessor proxies for the gwp-asan regions that are useful in
symbolizing dumps offline. Should be useful for Fuchsia to be able to
locate these internal pointers to stash the data in a minidump.
Reviewed By: cryptoad
Differential Revision: https://reviews.llvm.org/D107909
This fails with:
/tmp/FlagsTest-5761bc.o: In function `sancov.module_ctor_8bit_counters':
FlagsTest.cpp:(.text.sancov.module_ctor_8bit_counters[sancov.module_ctor_8bit_counters]+0x14): undefined reference to `__start___sancov_cntrs'
FlagsTest.cpp:(.text.sancov.module_ctor_8bit_counters[sancov.module_ctor_8bit_counters]+0x18): undefined reference to `__stop___sancov_cntrs'
<...>
Since https://reviews.llvm.org/D107374. However the changes
there don't seem to be the real fault so xfail while I look into it.
New tsan runtime will need to compress addresses/PCs to fewer bits.
Add CompressAddr/RestoreAddr functions that compress/restore
addresses to 44 bits.
Depends on D107744.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107745
Rename mapping field selectors according to the code style.
Reuse the actual field names, there is no need to invent
second set of names.
Depends on D107743.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107744
Currently there are 2 levels when selecting the active mapping:
the branchy ifdef tree + another ifdef tree in SelectMapping.
Moreover, there is an additional indirection for some platforms
via HAS_48_BIT_ADDRESS_SPACE define. This makes already complex
logic even more complex and almost impossible to read.
Remove one level of indirection and define the active mapping
in SelectMapping.
Depends on D107742.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107743
Remove direct uses of Mapping in preperation for removing Mapping type
(which we already don't have for all platforms).
Remove dependence on HAS_48_BIT_ADDRESS_SPACE in preparation for removing it.
As far as I see for Apple/Mac platforms !HAS_48_BIT_ADDRESS_SPACE
simply means SANITIZER_IOS.
Depends on D107741.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107742
Move the mapping checking logic from startup to unit tests
and test all mapping instead of just the active one.
This makes it much more feasible to make any global changes
to the mappings since we have 17 of them.
Depends on D107740.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D107741
Currently we have ifdef's for Go/C++ and Windows/non-Windows
in MemToShadow, MemToMeta, ShadowToMem. This does not allow
to test all mappings on a single platform.
Make all these functions support a superset of mappings for
all platforms by defining missing mapping consts to 0.
E.g. we always do ^A+B, but if A and B are defined to 0,
then these operations become no-op.
Depends on D107739.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107740
Define all fields to 0 for all mappings.
This allows to write portable code and tests.
For all existing cases 0 values work out of the box
because we check if an address belongs to the range
and nothing belongs to [0, 0] range.
Depends on D107738.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107739
Unify Go mapping naming with C++ naming to allow
writing portable code/tests that can work for both C++ and Go.
No functional changes.
Depends on D107737.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107738
First, the define conflicts with definition/testing of all mappings,
since it's not a global property anymore. Second, macros/ifdefs are bad.
Define kMidAppMemBeg/End to 0 to denote that there is no "mid" range instead.
Depends on D107736.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107737
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
Currently we have mapping selection duplicated 9 times.
Deduplicate it. No functional changes.
Depends on D107734.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107735
Currently we define/compile the mapping for a platform
only on that platform. This makes it impossible to unit-test
them on a single platform, and even to build test.
We have 17 of them and the Go mappings will be tested
only after a manual episodic update of the Go runtime.
Define all mappings always with unique names.
This will allow to unit-test them.
No functional changes.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107734
There were 2 issues reported on https://reviews.llvm.org/D105716:
1. FreeBSD phtread.h is annotated with thread-safety attributes
and this causes errors in gtest headers.
2. If sanitizers are compiled with an older versions of clang
(which supports the annotations, but has some false positives
in analysis not present in later versions of clang), compilation
fails with errors.
Switch the errors to warnings by default.
Some CI bots enable COMPILER_RT_ENABLE_WERROR, which should
turn these warnings back into errors.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D107826
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
Darwin/MachO TLV support was only getting built into the x86_64 slice, not the
x86_64h slice. This caused errors when using the ORC runtime on Haswell
machines.
rdar://81056700
54902e00d1 added a use of
/alternatename via a #pragma comment(linker); in MinGW mode, this
requires building with -fms-extensions. (This flag is added to
SANITIZER_COMMON_CFLAGS in the toplevel CMakeLists.txt.)
This avoids a warning when building in MinGW mode (about an unknown
pragma being ignored), and presumably also makes the code work as
intended.
Differential Revision: https://reviews.llvm.org/D107620
The Headers.CountersDelta field is an uint64_t, not a pointer,
so just cast to uint32_t to truncate it.
Differential Revision: https://reviews.llvm.org/D107619
The _zx_vmar_root_self function is not a system call but
a libc function declared in a separate header.
Reviewed By: gulfem
Differential Revision: https://reviews.llvm.org/D107616
When the builtins library isn't found, find_compiler_rt_library
returns NOTFOUND so we'll end up linking against -lNOTFOUND. We need
to check the return value before adding it to the list.
Differential Revision: https://reviews.llvm.org/D107627
The Solaris buildbots have been broken for some time by the unconditional
use of `NT_GNU_BUILD_ID`, e.g. Solaris/sparcv9
<https://lab.llvm.org/staging/#/builders/50/builds/4910> and Solaris/amd64
<https://lab.llvm.org/staging/#/builders/101/builds/3751>. Being a GNU
extension, it is not defined in `<sys/elf.h>`. However, providing a
fallback definition doesn't help because the code also relies on
`__ehdr_start`, another unportable GNU extension that most likely never
will be implemented in Solaris `ld`. Besides, there's reallly no point in
supporting build ids since they aren't used on Solaris at all.
This patch fixes this by making the relevant code conditional on the
definition of `NT_GNU_BUILD_ID`.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D107556
Include windows.h with an all lowercase filename; Windows SDK headers
aren't self consistent so they can't be used in an entirely
case sensitive setting, and mingw headers use all lowercase names
for such headers.
This fixes building after 881faf4190.
- Enable extra coverage counters on Windows.
- Update extra_counters.test to run on Windows also.
- Update TableLookupTest.cpp to include the required pragma/declspec for the extra coverage counters.
Patch By: MichaelSquires
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D106676
Recently in 0da172b176 thread safety warnings-as-errors were enabled.
However, googletest is currently not compatible with thread safety
annotations. On FreeBSD, which has the pthread functions marked with
such annotations, this results in errors when building the compiler-rt
tests:
In file included from compiler-rt/lib/interception/tests/interception_test_main.cpp:15:
In file included from llvm/utils/unittest/googletest/include/gtest/gtest.h:62:
In file included from llvm/utils/unittest/googletest/include/gtest/internal/gtest-internal.h:40:
llvm/utils/unittest/googletest/include/gtest/internal/gtest-port.h:1636:3: error: mutex 'mutex_' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
llvm/utils/unittest/googletest/include/gtest/internal/gtest-port.h:1633:32: note: mutex acquired here
GTEST_CHECK_POSIX_SUCCESS_(pthread_mutex_lock(&mutex_));
^
llvm/utils/unittest/googletest/include/gtest/internal/gtest-port.h:1645:32: error: releasing mutex 'mutex_' that was not held [-Werror,-Wthread-safety-analysis]
GTEST_CHECK_POSIX_SUCCESS_(pthread_mutex_unlock(&mutex_));
^
2 errors generated.
At some point googletest will hopefully be made compatible with thread
safety annotations, but for now add corresponding `-Wno-thread-*` flags
to `COMPILER_RT_GTEST_CFLAGS` to silence these warnings-as-errors.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D107491
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
Pass thr/pc args to MemoryResetRange as we do everywhere.
Currently they are unused by MemoryResetRange,
but there is no reason to be inconsistent.
Depends on D107562.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107563
clang-tidy warning requires qualifying auto pointers:
clang-tidy: warning: 'auto ctx' can be declared as 'auto *ctx' [llvm-qualified-auto]
Fix remaing cases we have in tsan.
Depends on D107561.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107562
None of the interceptors machinery is used/enabled for Go,
so don't include the header, it's not needed (must not be).
The problem is that we have fields in ThreadState that are
not present in the Go build, so changes in thread_interceptors.h
can cause Go build breakages due to missing fields.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107561
For symbolizer we only process SIGSEGV signals synchronously
(which means bug in symbolizer or in tsan).
But we still want to reset in_symbolizer to fail gracefully.
Symbolizer and user code use different memory allocators,
so if we don't reset in_symbolizer we can get memory allocated
with one being feed with another, which can cause more crashes.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107564
Use C++ casts and auto.
Rename to CollectThreadLeaks b/c it's only collecting, not reporting.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107568
Currently we hardcode u64 type for shadow everywhere
and do lots of uptr<->u64* casts. It makes it hard to
change u64 to another type (e.g. u32) and makes it easy
to introduce bugs.
Introduce RawShadow type and use it in MemToShadow, ShadowToMem,
IsShadowMem and throughout the code base as u64 replacement.
This makes it possible to change u64 to something else in future
and generally improves static typing.
Depends on D107481.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107482
MemToMeta returns u32*, so it's reasonable for IsMetaMem
to accept u32* as well.
Changing the argument type just removes few type casts.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107481
Previously the build used `-gline-tables-only` when `COMPILER_RT_DEBUG`
was off (default) and `-g` when `COMPILER_RT_DEBUG` was on. The end
result of this meant that the release build of the Sanitizer runtimes
were difficult to debug (e.g. information about variables and function
arguments were missing).
Presumably the reason for preferring `-gline-tables-only` for release
builds was to save space. However, for Apple platforms this doesn't
matter because debug info lives in separate `.dSYM` files (which aren't
shipped) rather than in the shipped `.dylib` files.
Now on Apple platforms we always emit full debug info if the compiler
supports it and we emit a fatal error if `-g` isn't supported.
rdar://79223184
Differential Revision: https://reviews.llvm.org/D107501
This change adds tests to make sure that SCUDO is being properly
included with llvm libc. This change also adds the toggles to properly
use SCUDO, as GWP-ASan is enabled by default and must be included for
SCUDO to function.
Reviewed By: sivachandra, hctim
Differential Revision: https://reviews.llvm.org/D106919
Found by an Android toolchain upgrade, inherited module constructors
(like init_have_lse_atomics from the builtins) can sneak into the hwasan
runtime. If these inherited constructors call hwasanified libc
functions, then the HWASan runtime isn't setup enough, and the code
crashes.
Mark the initialized as a high-priority initializer to fix this.
Reviewed By: pcc, yabinc
Differential Revision: https://reviews.llvm.org/D107391
Fixes PR51331. On FreeBSD, the elf headers don't (yet) provide the
ElfW(type) macro. However, there is a similar set of macros in the
<sys/elf-generic.h> header, of which `__ElfN(type)` exactly matches the
indended purpose.
Reviewed By: gulfem
Differential Revision: https://reviews.llvm.org/D107388
It will be needed in more functions like ReportRace
(the plan is to pass it through MemoryAccess to ReportRace)
and this move will allow to split the huge tsan_rtl.h into parts
(e.g. move FastState/Shadow definitions to a separate header).
Depends on D107465.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107466
Add kAccessExternal memory access flag that denotes
memory accesses with PCs that may have kExternalPCBit set.
In preparation for MemoryAccess refactoring.
Currently unused, but will allow to skip a branch.
Depends on D107464.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107465
Add kAccessFree memory access flag (similar to kAccessVptr).
In preparation for MemoryAccess refactoring.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107464
Currently we use passive spinning with internal_sched_yield to wait
in __cxa_guard_acquire/pthread_once. Passive spinning tends to degrade
ungracefully under high load. Use FutexWait/Wake instead.
Depends on D107359.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D107360
Currently we effectively duplicate "once" logic for __cxa_guard_acquire
and pthread_once. Unify the implementations.
This is not a no-op change:
- constants used for pthread_once are changed to match __cxa_guard_acquire
(__cxa_guard_acquire constants are tied to ABI, but it does not seem
to be the case for pthread_once)
- pthread_once now also uses PotentiallyBlockingRegion annotations
- __cxa_guard_acquire checks thr->in_ignored_lib to skip user synchronization
It's unclear if these 2 differences are intentional or a mere sloppy inconsistency.
Since all tests still pass, let's assume the latter.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D107359
Atomic functions are semi-hot in profiles.
The CHECKs verify values passed by compiler
and they never fired, so replace them with DCHECKs.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D107373
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
On macOS the unit tests currently rely on libmalloc being used for
allocations (due to no functioning interceptors) but also having the
ASan/TSan allocator initialized in the same process.
This leads to crashes with the macOS 12.0 libmalloc nano allocator so
disable use of the allocator while running unit tests as a workaround.
rdar://80086125
Differential Revision: https://reviews.llvm.org/D107412
A `Vector` that doesn't require an initial `reserve()` (eg: with a
default, or small enough capacity) can have a constant initializer.
This changes the code in a few places to make that possible:
- mark a few other functions as `constexpr`
- do without any `reinterpret_cast`
- allow to skip `reserve` from `init`
Differential Revision: https://reviews.llvm.org/D107308
mallopt calls are left-over from the times we used
__libc_malloc/__libc_free for internal allocations.
Now we have own internal allocator, so this is not needed.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107342
We currently use ad-hoc spin waiting to synchronize thread creation
and thread start both ways. But spinning tend to degrade ungracefully
under high contention (lots of threads are created at the same time).
Use semaphores for synchronization instead.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107337
Currently unaligned access functions are defined in tsan_interface.cpp
and do a real call to MemoryAccess. This means we have a real call
and no read/write constant propagation.
Unaligned memory access can be quite hot for some programs
(observed on some compression algorithms with ~90% of unaligned accesses).
Move them to tsan_interface_inl.h to avoid the additional call
and enable constant propagation.
Also reorder the actual store and memory access handling for
__sanitizer_unaligned_store callbacks to enable tail calling
in MemoryAccess.
Depends on D107282.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D107283
Add AccessVptr access type.
For now it's converted to the same thr->is_vptr_access,
but later it will be passed directly to ReportRace
and will enable efficient tail calling in MemoryAccess function
(currently __tsan_vptr_update/__tsan_vptr_read can't use
tail calls in MemoryAccess because of the trailing assignment
to thr->is_vptr_access).
Depends on D107276.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D107282
Currently we have MemoryAccess function that accepts
"bool kAccessIsWrite, bool kIsAtomic" and 4 wrappers:
MemoryRead/MemoryWrite/MemoryReadAtomic/MemoryWriteAtomic.
Such scheme with bool flags is not particularly scalable/extendable.
Because of that we did not have Read/Write wrappers for UnalignedMemoryAccess,
and "true, false" or "false, true" at call sites is not very readable.
Moreover, the new tsan runtime will introduce more flags
(e.g. move "freed" and "vptr access" to memory acccess flags).
We can't have 16 wrappers and each flag also takes whole
64-bit register for non-inlined calls.
Introduce AccessType enum that contains bit mask of
read/write, atomic/non-atomic, and later free/non-free,
vptr/non-vptr.
Such scheme is more scalable, more readble, more efficient
(don't consume multiple registers for these flags during calls)
and allows to cover unaligned and range variations of memory
access functions as well.
Also switch from size log to just size.
The new tsan runtime won't have the limitation of supporting
only 1/2/4/8 access sizes, so we don't need the logarithms.
Also add an inline thunk that converts the new interface to the old one.
For inlined calls it should not add any overhead because
all flags/size can be computed as compile time.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D107276
... and rename it to 'warnIfNonZero' to better-reflect what it actually
does.
The goal is to minimize the amount of logic that's conditionally
compiled under '#if __APPLE__'.
Add new fixed-size vector clock for the new tsan runtime.
For now it's unused.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107167
Currently we save the creation stack for sync objects always.
But it's not needed to some sync objects, most notably atomics.
We simply don't use atomic creation stack anywhere.
Allow callers to control saving of the creation stack
and don't save it for atomics.
Depends on D107257.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107258
MetaMap::GetSync shows up in profiles,
so add LIKELY/UNLIKELY annotations.
Depends on D107256.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107257
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
ProcessPendingSignals is called in all interceptors
and user atomic operations. Make the fast-path check
(no pending signals) inlinable.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107217
Some bots started failing with the following error
after changing Alloc to New. Change it back.
ThreadSanitizer: CHECK failed: ((locked[i].recursion)) == ((0))
4 __sanitizer::CheckedMutex::CheckNoLocks()
5 __tsan::ScopedInterceptor::~ScopedInterceptor()
6 memset
7 __tsan::New<__tsan::ExpectRace>()
8 __tsan::AddExpectRace()
9 BenignRaceImpl()
Differential Revision: https://reviews.llvm.org/D107212
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
We currently build tests without -g, which is quite inconvenient.
Crash stacks don't have line numbers, gdb don't how line numbers either.
Always build tests with -g.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107168
"Expected" races is a very ancient facility used in tsanv1 tests.
It's not used/needed anymore. Remove it.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107175
Currently we setup either sigaction signal handler with 3 arguments
or old style signal handler with 1 argument depending on user handler type.
This unnecessarily complicates code. Always setup sigaction handler.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107186
This fixes support for merging profiles which broke as a consequence
of e50a38840d. The issue was missing
adjustment in merge logic to account for the binary IDs which are
now included in the raw profile just after header.
In addition, this change also:
* Includes the version in module signature that's used for merging
to avoid accidental attempts to merge incompatible profiles.
* Moves the binary IDs size field after version field in the header
as was suggested in the review.
Differential Revision: https://reviews.llvm.org/D107143
Gulfem Savrun Yeniceri