This patch use the same way as the https://reviews.llvm.org/rGfe1fa43f16beac1506a2e73a9f7b3c81179744eb to handle the thread local variable.
It allocates 2 * pointerSize space in GOT to represent the thread key and data address. Instead of using the _tls_get_addr function, I customed a function __orc_rt_elfnix_tls_get_addr to get the address of thread local varible. Currently, this is a wip patch, only one TLS relocation R_X86_64_TLSGD is supported and I need to add the corresponding test cases.
To allocate the TLS descriptor in GOT, I need to get the edge kind information in PerGraphGOTAndPLTStubBuilder, So I add a `Edge::Kind K` argument in some functions in PerGraphGOTAndPLTStubBuilder.h. If it is not suitable, I can think further to solve this problem.
Differential Revision: https://reviews.llvm.org/D109293
I found that the initial corpus allocation of fork mode has certain defects.
I designed a new initial corpus allocation strategy based on size grouping.
This method can give more energy to the small seeds in the corpus and
increase the throughput of the test.
Fuzzbench data (glibfuzzer is -fork_corpus_groups=1):
https://www.fuzzbench.com/reports/experimental/2021-08-05-parallel/index.html
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D105084
Extend the existing single-pass algorithm for `Merger::Merge` with an algorithm that gives better results. This new implementation can be used with a new **set_cover_merge=1** flag.
This greedy set cover implementation gives a substantially smaller final corpus (40%-80% less testcases) while preserving the same features/coverage. At the same time, the execution time penalty is not that significant (+50% for ~1M corpus files and far less for smaller corpora). These results were obtained by comparing several targets with varying size corpora.
Change `Merger::CrashResistantMergeInternalStep` to collect all features from each file and not just unique ones. This is needed for the set cover algorithm to work correctly. The implementation of the algorithm in `Merger::SetCoverMerge` uses a bitvector to store features that are covered by a file while performing the pass. Collisions while indexing the bitvector are ignored similarly to the fuzzer.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D105284
The Solaris buildbots have been broken for some time:
In file included from /opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/compiler-rt/lib/asan/asan_interceptors.cpp:174:
/opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:4000:19: error: use of undeclared identifier 'wordexp_wrde_dooffs'
((flags & wordexp_wrde_dooffs) ? p->we_offs : 0) + p->we_wordc;
^
This was caused by D108646 <https://reviews.llvm.org/D108646>; the fix is
equivalent to D108838 <https://reviews.llvm.org/D108838>.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D109193
[ubsan] warn inside the sigaction interceptor if static linking is suspected, and continue instead of crashing on null deref
Reviewed By: kostik
Differential Revision: https://reviews.llvm.org/D109081
ASan, LSan, MSan and UBSan all allow to use environment variable `*SAN_SYMBOLIZER_PATH` to pass the symbolizer path, this patch add `TSAN_SYMBOLIZER_PATH` to TSan.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108911
In reviews.llvm.org/D108316 I missed a few instances of REAL(strlen) and
this change fixes that, as well as restoring one that seems like it
shouldn't have been changed.
Reviewed By: hctim, vitalybuka
Differential Revision: https://reviews.llvm.org/D108843
In this mode libc++ headers end up in two directories:
* include/<triple>/c++/v1 for the site config header
* include/c++/v1 for everything else
Also switch from -I to -isystem.
Differential Revision: https://reviews.llvm.org/D108841
Replace D107203, because __llvm_profile_set_file_object is usually used when the
process doesn't have permission to open/create file. That patch trying to copy
from old profile to new profile contradicts with the usage.
Differential Revision: https://reviews.llvm.org/D108242
qsort can reuse qsort_r if available.
bsearch always passes key as the first comparator argument, so we
can use it to wrap the original comparator.
Differential Revision: https://reviews.llvm.org/D108751
We have to avoid calling renameat2 and clone on FreeBSD.
Additionally, the mcontext structure has different members.
Reviewed By: jrtc27, luismarques
Differential Revision: https://reviews.llvm.org/D103886
Breaks realpath(, nullptr) for all sanitizers.
Somehow INTERCEPT_FUNCTION and INTERCEPT_FUNCTION_VER return
false even if everything seemingly right.
And this is the issue for COMMON_INTERCEPT_FUNCTION_GLIBC_VER_MIN.
There is a check in every sanitlizer:
if (!INTERCEPT_FUNCTION_VER(name, ver) && !INTERCEPT_FUNCTION(name))
For non-versioned interceptors when INTERCEPT_FUNCTION returns false
it's not considered fatal, and it just prints a warning.
However INTERCEPT_FUNCTION_VER in this case will fallback to
INTERCEPT_FUNCTION replacing realpath with wrong version.
We need to investigate that before relanding the patch.
This reverts commit faef0d042f.
In that case it is very likely that there will be a tag mismatch anyway.
We handle the case that the pointer belongs to neither of the allocators
by getting a nullptr from allocator.GetBlockBegin.
Reviewed By: hctim, eugenis
Differential Revision: https://reviews.llvm.org/D108383
Handle the case of wordexp being invoked with WRDE_DOOFFS and
we.we_offs set to a positive value, which will result in NULL
entries prepended to the result. With this change the entire
result, containing both NULL and actual entries, is unpoisoned.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108646
* c_api_tests was failing to build after the API change to
__orc_rt_CWrapperFunctionResultAllocate
* wrapper_function_utils_test was causing an assertion failure, because
it was creating a result for `void(void)` with Size = 0, but seeing an
uninitialized pointer, which it considered to be an out-of-bound
error.
I noticed locally that making modifications to c_api.h is not causing
these unit tests to be rebuilt, which may be how the bug slipped in in
the first place.
Differential Revision: https://reviews.llvm.org/D108649
Fixes a regression when the allocator is disabled, and a dirty
allocation is re-used. This only occurs when the allocator is disabled,
so a test-only fix, but still necessary.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D108650
Set SA_SIGINFO only if we set sighandler, or we can set the flag, and
return it as 'old' without actual sigaction set.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D108616
* Cannot use sizeof() on another union member
* nullptr vs NULL
* () vs (void)
Incidentally, fix an incorrect comment about memory ownership on the
argument to __orc_rt_CreateCWrapperFunctionResultFromOutOfBandError,
which is copied, not moved.
llvm-libc is expected to be built with sanitizers and not use interceptors in
the long run. For now though, we have a hybrid process, where functions
implemented in llvm-libc are instrumented, and glibc fills and sanitizer
interceptors fill in the rest.
Current sanitizers have an invariant that the REAL(...) function called from
inside of an interceptor is uninstrumented. A lot of interceptors call strlen()
in order to figure out the size of the region to check/poison. Switch these
callsites over to the internal, unsanitized implementation.
Reviewed By: hctim, vitalybuka
Differential Revision: https://reviews.llvm.org/D108316
WrapperFunctionResult no longer supports wrapping constant data, so this patch
provides direct non-const access to the wrapped data. Since wrapped data can now
be written, the WrapperFunctionResult::allocate method can be simplified to
return a WrapperFunctionResult.
This is essentially the same change (and with the same motivation) as LLVM
commit 8b117830b1, but applied to the ORC runtime's WrapperFunctionResult code.
In the raw profile, binary ids immediately follow the header so when
computing counters offset we need to account for the new section.
Differential Revision: https://reviews.llvm.org/D108608
In that case it is very likely that there will be a tag mismatch anyway.
We handle the case that the pointer belongs to neither of the allocators
by getting a nullptr from allocator.GetBlockBegin.
Reviewed By: hctim, eugenis
Differential Revision: https://reviews.llvm.org/D108383
This avoids pulling in all of them if only one of them is needed
(if builtins are built without -ffunction-sections), and matches how
the similar aliases for AEABI are set up.
Differential Revision: https://reviews.llvm.org/D107815
With unquoted ${CMAKE_CXX_FLAGS}, the REGEX fails when it's empty:
```CMake Error at lib/scudo/standalone/CMakeLists.txt:14 (string):
string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
command.```
Change 636428c727 enabled BlockingRegion hooks for pthread_once().
Unfortunately this seems to cause crashes on Mac OS X which uses
pthread_once() from locations that seem to result in crashes:
| ThreadSanitizer:DEADLYSIGNAL
| ==31465==ERROR: ThreadSanitizer: stack-overflow on address 0x7ffee73fffd8 (pc 0x00010807fd2a bp 0x7ffee7400050 sp 0x7ffee73fffb0 T93815)
| #0 __tsan::MetaMap::GetSync(__tsan::ThreadState*, unsigned long, unsigned long, bool, bool) tsan_sync.cpp:195 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x78d2a)
| #1 __tsan::MutexPreLock(__tsan::ThreadState*, unsigned long, unsigned long, unsigned int) tsan_rtl_mutex.cpp:143 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x6cefc)
| #2 wrap_pthread_mutex_lock sanitizer_common_interceptors.inc:4240 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x3dae0)
| #3 flockfile <null>:2 (libsystem_c.dylib:x86_64+0x38a69)
| #4 puts <null>:2 (libsystem_c.dylib:x86_64+0x3f69b)
| #5 wrap_puts sanitizer_common_interceptors.inc (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x34d83)
| #6 __tsan::OnPotentiallyBlockingRegionBegin() cxa_guard_acquire.cpp:8 (foo:x86_64+0x100000e48)
| #7 wrap_pthread_once tsan_interceptors_posix.cpp:1512 (libclang_rt.tsan_osx_dynamic.dylib:x86_64+0x2f6e6)
From the stack trace it can be seen that the caller is unknown, and the
resulting stack-overflow seems to indicate that whoever the caller is
does not have enough stack space or otherwise is running in a limited
environment not yet ready for full instrumentation.
Fix it by reverting behaviour on Mac OS X to not call BlockingRegion
hooks from pthread_once().
Reported-by: azharudd
Reviewed By: glider
Differential Revision: https://reviews.llvm.org/D108305
The shadow for a short granule is stored in the last byte of the
granule. Currently, if there's a tail-overwrite report (a
buffer-overflow-write in uninstrumented code), we report the shadow byte
as a mismatch against the magic.
Fix this bug by slapping the shadow into the expected value. This also
makes sure that if the uninstrumented WRITE does clobber the shadow
byte, it reports the shadow was actually clobbered as well.
Reviewed By: eugenis, fmayer
Differential Revision: https://reviews.llvm.org/D107938
D104556 change the CountersPtr to be relative, however, it did not
update the pointer initialization in __llvm_profile_register_function,
so the platform (eg:AIX) that use __llvm_profile_register_function is now totaly
broken, any PGO code will SEGV.
This patch update the code to reflect that the Data->CountersPtr is now
relative.
Reviewed By: MaskRay, davidxl
Differential Revision: https://reviews.llvm.org/D108304
According to comments at https://reviews.llvm.org/D107911,
Trace.MemoryAccessSize fails on Mac buildbots.
Because this test is newly introduced, and is the only user of the code
added in that patch, disable the test on Mac till the problem is
resolved.
Differential Revision: https://reviews.llvm.org/D108294
This change adds support to ORCv2 and the Orc runtime library for static
initializers, C++ static destructors, and exception handler registration for
ELF-based platforms, at present Linux and FreeBSD on x86_64. It is based on the
MachO platform and runtime support introduced in bb5f97e3ad.
Patch by Peter Housel. Thanks very much Peter!
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D108081
Before this change we were locking the StackDepot in the fork()
interceptor. This results in a deadlock when allocator functions are
used in a pthread_atfork() callback.
Instead, set up a pthread_atfork() callback at init that locks/unlocks
both StackDepot and the allocator. Since our callback is set up very
early, the pre-fork callback is executed late, and both post-fork ones
are executed early, which works perfect for us.
Differential Revision: https://reviews.llvm.org/D108063
This reverts commit 797fe59e6b.
The use of "EventType type : 3" is replicated for all Event structs and
therefore was still present. As a result this still caused failures on
older GCCs (9.2 or 8.3 or earlier).
The particular bot that was failing due to buggy GCC was fixed by
fef39cc472.
Therefore, no reason to keep the workaround around; revert it.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D108192
D104248 moved the call to GetThreadStackAndTls to before the
initialization of the ring buffer TLS slot. As a result, if libc
is instrumented we crash in pthread_getattr_np which is called from
__sanitizer::GetThreadStackTopAndBottom.
Fix the problem by moving the stack ring buffer initialization before
the call to InitStackAndTls.
Differential Revision: https://reviews.llvm.org/D108184
Some compilers started complaining about the test:
tsan_trace_test.cpp:128:21: error: missing field 'type' initializer
Fix it by initializing all 5 fields, even though the type field will be
reset in the for loop.
Differential Revision: https://reviews.llvm.org/D108207
This removes the -Werror compilation flag for x64 linux to work around a gcc bug.
GCC 8.3 reports '__tsan::v3::Event::type’ is too small to hold all values of ‘enum class __tsan::v3::EventType’
incorrectly which gets promoted to an error and causes the build to fail.
This is a redo of D108089 that broke some 32-bit builds.
`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/D108152
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
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
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
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
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
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
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
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
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
"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
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
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
Multiple copies of emulated TLS state means inconsistent results when
accessing the same thread-local variable from different shared objects
(https://github.com/android/ndk/issues/1551). Making `__emutls_get_address`
be a weak default visibility symbol should make the dynamic linker
ensure only a single copy gets used at runtime. This is best-effort, but
the more robust approach of putting emulated TLS into its own shared
object would (a) be a much bigger change, and (b) shared objects are
pretty heavyweight, and adding a new one to a space-constrained
environment isn't an easy sell. Given the expected rarity of direct
accesses to emulated TLS variables across different shared objects, the
best-effort approach should suffice.
Reviewed By: danalbert, rprichard
Differential Revision: https://reviews.llvm.org/D107127
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
Change `CountersPtr` in `__profd_` to a label difference, which is a link-time
constant. On ELF, when linking a shared object, this requires that `__profc_` is
either private or linkonce/linkonce_odr hidden. On COFF, we need D104564 so that
`.quad a-b` (64-bit label difference) can lower to a 32-bit PC-relative relocation.
```
# ELF: R_X86_64_PC64 (PC-relative)
.quad .L__profc_foo-.L__profd_foo
# Mach-O: a pair of 8-byte X86_64_RELOC_UNSIGNED and X86_64_RELOC_SUBTRACTOR
.quad l___profc_foo-l___profd_foo
# COFF: we actually use IMAGE_REL_AMD64_REL32/IMAGE_REL_ARM64_REL32 so
# the high 32-bit value is zero even if .L__profc_foo < .L__profd_foo
# As compensation, we truncate CountersDelta in the header so that
# __llvm_profile_merge_from_buffer and llvm-profdata reader keep working.
.quad .L__profc_foo-.L__profd_foo
```
(Note: link.exe sorts `.lprfc` before `.lprfd` even if the object writer
has `.lprfd` before `.lprfc`, so we cannot work around by reordering
`.lprfc` and `.lprfd`.)
With this change, a stage 2 (`-DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_BUILD_INSTRUMENTED=IR`)
`ld -pie` linked clang is 1.74% smaller due to fewer R_X86_64_RELATIVE relocations.
```
% readelf -r pie | awk '$3~/R.*/{s[$3]++} END {for (k in s) print k, s[k]}'
R_X86_64_JUMP_SLO 331
R_X86_64_TPOFF64 2
R_X86_64_RELATIVE 476059 # was: 607712
R_X86_64_64 2616
R_X86_64_GLOB_DAT 31
```
The absolute function address (used by llvm-profdata to collect indirect call
targets) can be converted to relative as well, but is not done in this patch.
Differential Revision: https://reviews.llvm.org/D104556
Make New<>() a variadic function template and forward any arguments to
the constructor. std::forward<>() is inlined to avoid including
<utility>.
Differential Revision: https://reviews.llvm.org/D107147
We frequenty allocate sizeof(T) memory and call T ctor on that memory
(C++ new keyword effectively). Currently it's quite verbose and
usually takes 2 lines of code.
Add New<T>() helper that does it much more concisely.
Rename internal_free to Free that also sets the pointer to nullptr.
Shorter and safer.
Rename internal_alloc to Alloc, just shorter.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D107085
The updated lots_of_threads.c test with 300 threads
started running for too long on machines with low
hardware parallelism (e.g. taskset -c 0-1).
On lots of CPUs it finishes in ~2 secs. But with
taskset -c 0-1 it runs for hundreds of seconds
effectively spinning in the barrier in the sleep loop.
We now have the handy futex API in sanitizer_common.
Use it instead of the passive spin loop.
It makes the test run only faster with taskset -c 0-1,
it runs for ~1.5 secs, while with full parallelism
it still runs for ~2 secs (but consumes less CPU time).
Depends on D107131.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D107132
Adds magic version header to AllocatorState. This can be used by
out-of-process crash handlers, like Crashpad on Fuchsia, to do offline
reconstruction of GWP-ASan crash metadata.
Crashpad on Fuchsia is intending on dumping the AllocationMetadata pool
and the AllocatorState directly into the minidump. Then, using the
version number, they can unpack the data on serverside using a versioned
unpack tool.
Also add some asserts to make sure the version number gets bumped if the
internal structs get changed.
Reviewed By: eugenis, mcgrathr
Differential Revision: https://reviews.llvm.org/D106690
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
We call non-inlinable Initialize from all interceptors/syscalls,
but most of the time runtime is already initialized and this just
introduces unnecessary overhead.
Add LazyInitialize that (1) inlinable, (2) does nothing if
.preinit_array is enabled (expected case on Linux).
Depends on D107071.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107072
We are very paranoid with CHECKs in all Java entry points.
These CHECKs were added along with Java support.
At that point it wasn't clear what exactly to expect from JVM part
and if JVM part is correct or not. Thus CHECK paranoia.
These CHECKs never fired in practice, but we pay runtime cost
in every entry point all the time.
Replace CHECKs with DCHECKs.
Depends on D107069.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107071
We used to call Initialize in every Java point.
That was removed in 6563bb53b5 ("tsan: don't use caller/current PC in Java interfaces").
The intention was to add a single Initialize to __tsan_java_init instead.
Do that.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107069
Add intrusive doubly-linked list container template, IList.
It will be used in the new tsan runtime.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D107050
Switch x86_64 requirement for optimized code from SSE3 to SSE4.2.
The new tsan runtime will need few instructions that are only
supported by SSE4:
_mm_max_epu32
_mm_extract_epi8
_mm_insert_epi32
SSE3 was introcued in 2004 and SSE4 in 2006:
https://en.wikipedia.org/wiki/SSE3https://en.wikipedia.org/wiki/SSE4
We are still providing non-optimized C++ version of the code,
so either way it's possible to build tsan runtime for any CPU.
But for Go this will bump strict requirement for -race because
Go contains prebuilt versions and these will be built with -msse4.2.
But requiring a CPU produced at least in 2006 looks reasonable for
a debugging tool (more reasonable than disabling optimizations
for everybody).
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D106948
This CL modifies the PlatformUnpoisonStacks so that fuchsia can
implement its own logic for unpoisoning the stacks.
For the general case, the behavior is the same as with regular asan: it
will unpoison everything from the current stack pointer until the base
of the stack (stack top).
In some situations, the current stack might not be the same as the
default stack. In those cases, the code will now unpoison the entire
default stack, and will also unpoison the current page of the stack.
Reviewed By: mcgrathr
Differential Revision: https://reviews.llvm.org/D106835
This commit fixes the CFI directives in the crash trampoline so
libunwind can get a backtrace during a crash.
In order to get a backtrace from a libfuzzer crash in fuchsia, we
resume execution in the crashed thread, forcing it to call the
StaticCrashHandler. We do this by setting a "crash trampoline" that has
all the necessary cfi directives for an unwinder to get full backtrace
for that thread.
Due to a bug in libunwind, it was not possible to restore the RSP
pointer, as it was always set to the call frame address (CFA). The
previous version worked around this issue by setting the CFA to the
value of the stack pointer at the point of the crash.
The bug in libunwind is now fixed[0], so I am correcting the CFI
annotations so that the CFA correctly points to the beginning of the
trampoline's call frame.
[0]: https://reviews.llvm.org/D106626
Reviewed By: mcgrathr
Differential Revision: https://reviews.llvm.org/D106725
Currently __tsan_atomic* functions do FuncEntry/Exit using caller PC
and then use current PC (pointing to __tsan_atomic* itself) during
memory access handling. As the result the top function in reports
involving atomics is __tsan_atomic* and the next frame points to user code.
Remove FuncEntry/Exit in atomic functions and use caller PC
during memory access handling. This removes __tsan_atomic*
from the top of report stacks, so that they point right to user code.
The motivation for this is performance.
Some atomic operations are very hot (mostly loads),
so removing FuncEntry/Exit is beneficial.
This also reduces thread trace consumption (1 event instead of 3).
__tsan_atomic* at the top of the stack is not necessary
and does not add any new information. We already say
"atomic write of size 4", "__tsan_atomic32_store" does not add
anything new.
It also makes reports consistent between atomic and non-atomic
accesses. For normal accesses we say "previous write" and point
to user code; for atomics we say "previous atomic write" and now
also point to user code.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D106966
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
We strip all frames below main but in some cases it may be not enough.
Namely, when main is instrumented but does not call any other instrumented code.
In this case __tsan_func_entry in main obtains PC pointing to __libc_start_main
(as we pass caller PC to __tsan_func_entry), but nothing obtains PC pointing
to main itself (as main does not call any instrumented code).
In such case we will not have main in the stack, and stripping everything
below main won't work.
So strip __libc_start_main explicitly as well.
But keep stripping of main because __libc_start_main is glibc/linux-specific,
so looking for main is more reliable (and usually main is present in stacks).
Depends on D106957.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D106958
Caller PC is plain harmful as native caller PC has nothing to do with Java code.
Current PC is not particularly useful and may be somewhat confusing for Java users
as it makes top frame to point to some magical __tsan function.
But obtaining and using these PCs adds runtime cost for every java event.
Remove these PCs. Rely only on official Java frames.
It makes execution faster, code simpler and reports better.
Depends on D106956.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D106957
We maintain information about Java allocations,
but for some reason never printed it in reports.
Print it.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D106956
We used to count number of allocations/bytes based on the type
and maybe record them in heap block headers.
But that's all in the past, now it's not used for anything.
Remove the mblock type.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D106971
Remove pc argument of ThreadIgnoreEnd, ThreadIgnoreSyncEnd
and AcquireGlobal functions. It's unused and in some places
we don't even have a pc and pass 0 anyway.
Don't confuse readers and don't pretend that pc is needed
and that passing 0 is somehow deficient.
Use simpler convention for ThreadIgnoreBegin and ThreadIgnoreSyncBegin:
accept only pc instread of pc+save_stack. 0 pc means "don't save stack".
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D106973
Currently the barrier supports only 256 threads,
this does not allow to write reliable tests that use more threads.
Bump max number of threads to 1024 to support writing
good stress tests.
Also replace sched_yield() with usleep(100) on the wait path.
If we write tests that create hundreds of threads (and dozens
of tests can run in parallel), yield would consume massive
amounts of CPU time for spinning.
Depends on D106952.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D106953
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.
This will just be a call into __sanitizer_fill_shadow defined in the fuchsia source tree. This depends on D105663.
Differential Revision: https://reviews.llvm.org/D105664
This is empty for now, but we will add a check that TBI is enabled once the
tagged pointer ABI for zircon is finalized. This depends on D105667.
Differential Revision: https://reviews.llvm.org/D105668
On Apple platforms the builtins may be built for both arm64 and arm64e.
With Makefile generators separate targets are built using Make sub-invocations.
This causes a race when creating the symlink which may sometimes fail.
Work around this by using a custom target that the builtin targets depend on.
This causes any sub-invocations to depend on the symlinks having been created before.
Mailing list thread: https://lists.llvm.org/pipermail/llvm-dev/2021-July/151822.html
Reviewed By: thakis, steven_wu
Differential Revision: https://reviews.llvm.org/D106305
Now that Mutex is blocking there is no point in using BlockingMutex.
Switch to Mutex.
Depends on D106379.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D106560
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
David Carlier
gtt1995