Switch `LongJmp` over to lookup JmpBuf via plain old (unmangled) SP.
This makes the computation of mangled SPs in the TSan assembly files
unnecessary, which will be cleaned up in follow-up revisions.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D63942
llvm-svn: 364818
TSan needs to infer which calls to setjmp/longjmp are corresponding
pairs. My understanding is, that we can't simply use the jmp_buf
address, since this buffer is just a plain data structure storing the
environment (registers) with no additional semantics, i.e., it can be
copied around and is still expected to work. So we use the stack pointer
(SP) instead.
The setjmp interceptor stores some metadata, which is then consumed in
the corresponding call to longjmp. We use the SP as an "index" (stable
identifier) into the metadata table. So far so good.
However, when mangling is used, the setjmp interceptor observes the
UNmangled SP, but the longjmp interceptor only knows the mangled value
for SP. To still correlate corresponding pairs of calls, TSan currently
derives the mangled representation in setjmp and uses it as the stable
identifer, so that longjmp can do it's lookup.
Currently, this works since "mangling" simply means XOR with a secret
value. However, in the future we want to use operations that do not
allow us to easily go from unmangled -> mangled (pointer
authentication). Going from mangled -> unmangled should still be
possible (for pointer authentication it means zeroing a few bits).
This patch is part 1 of changing set/longjmp interceptors to use the
unmangled SP for metadata lookup. Instead of deriving the mangled SP in
setjmp, we will derive the unmangled SP in longjmp. Since this change
involves difficult-to-test code, it will be done in (at least) 2 parts:
This patch only replicates the existing behavior and checks that the
newly computed value for SP matches with what we have been doing so far.
This should help me to fix issues on architectures I cannot test
directly. I tested this patch on x86-64 (Linux/Darwin) and arm64
(Darwin).
This patch will also address an orthogonal issue: there is a lot of code
duplication in the assembly files, because the
`void __tsan_setjmp(uptr sp, uptr mangled_sp)` already demands the
mangled SP. This means that the code for computing the mangled SP is
duplicated at every call site (in assembly).
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D60981
llvm-svn: 364662
On Linux both version of the INTERCEPT_FUNCTION macro now return true
when interception was successful. Adapt and cleanup some usages.
Also note that `&(func) == &WRAP(func)` is a link-time property, but we
do a runtime check.
Tested on Linux and macOS.
Previous attempt reverted by: 5642c3feb0
This attempt to bring order to the interceptor macro goes the other
direction and aligns the Linux implementation with the way things are
done on Windows.
Reviewed By: vitalybuka, rnk
Differential Revision: https://reviews.llvm.org/D61358
llvm-svn: 359725
They need to have same AddressSpaceView and MapUnmapCallback.
Reviewers: eugenis
Subscribers: kubamracek, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D61168
llvm-svn: 359719
Changing INTERCEPT_FUNCTION to return void is not functionally correct.
IMO the best way to communicate failure or success of interception is
with a return value, not some external address comparison.
This change was also creating link errors for _except_handler4_common,
which is exported from ucrtbase.dll in 32-bit Windows.
Also revert dependent changes r359362 and r359466.
llvm-svn: 359611
Originally this code as added for 64-bit platform and was never changed.
Add static_assert to make sure that we have correct map on all platforms.
llvm-svn: 359269
In libdispatch, dispatch_apply is implemented in terms of
dispatch_apply_f. Unfortunately, this means that we can't implement the
interceptor for dispatch_apply_f by forwarding to the dispatch_apply
interceptor.
In the interceptor dispatch_apply_f, we can't use WRAP(dispatch_apply).
WRAP(dispatch_apply) -> REAL(dispatch_apply_f). Requires duplication of
some setup code.
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D59526
llvm-svn: 356467
Including <dispatch/dispatch.h> and <Blocks.h> transitively pulls in
other system headers. Let's try to avoid that.
Blocks.h: compiler-rt already includes a blocks runtime. Just use the
header file that comes with it.
dispatch.h: Declare the bare minimum required for our implementation,
i.e., everything needed to define the interceptors, but not the
interceptors themselves. See tsan_dispatch_defs.h. I spotted a few other
places in compile-rt, where we declare libdispatch types. Maybe this
file can be moved to sanitizer_common if we deem it useful enough.
tsan_libdispatch.cc now compiles on Linux/Clang (requires support for
-fblocks). Linking still requires some manual configuration.
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D59145
llvm-svn: 356201
On Linux (and other non-Darwin platforms) we need to initialize
interceptors. Since tsan_libdispatch.cc is compiled optionally, add a
weak default implementation of `InitializeLibdispatchInterceptors`.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D59113
llvm-svn: 355717
Most libdispatch functions come in two variants: callbacks can be
specified via blocks or function pointers. Some of our interceptors for
the block variant actually forward to the function variant. However, on
Linux, `DECLARE_REAL(name)` has to appear before `REAL(name)`.
This patch reorders _f variant interceptors before _b variants
where possible and forward declares the _f variant in the remaining
cases (cyclic dependency between _f and _b interceptors).
Also rename macro to DISPATCH_INTERCEPT_ASYNC_F for better consistency.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D59067
llvm-svn: 355619
This is a new attempt for bringing TSan libdispatch support to Linux.
The main issue with the last patch (https://reviews.llvm.org/D53171) was
that we want to avoid building a separate library.
The updated plan is as follows:
1) Hide libdispatch support behind a flag: true on Darwin, false
elsewhere. If flag is specified, assume that libdispatch header and
-flbocks is available for building. This way we can directly include
the libdispatch header and rely on blocks runtime for our
implementation.
2) Optionally/weakly intercept libdispatch API functions.
This patch accomplishes 1). It compiles (without the flag enabled) on
Linux. Follow-up patches will provide 2) and enabling of tests on Linux.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D58935
llvm-svn: 355538
GetStackTrace is a implementation detail of BufferedStackTrace. Make it
a private method.
Reviewed By: vitalybuka
Differential-Revision: https://reviews.llvm.org/D58753
llvm-svn: 355232
Retrying without replacing call sites in sanitizer_common (which might
not have a symbol definition).
Add new Unwind API. This is the final envisioned API with the correct
abstraction level. It hides/slow fast unwinder selection from the caller
and doesn't take any arguments that would leak that abstraction (i.e.,
arguments like stack_top/stack_bottom).
GetStackTrace will become an implementation detail (private method) of
the BufferedStackTrace class.
Reviewers: vitalybuka
Differential Revision: https://reviews.llvm.org/D58741
> llvm-svn: 355168
llvm-svn: 355172
Add new Unwind API. This is the final envisioned API with the correct
abstraction level. It hides/slow fast unwinder selection from the caller
and doesn't take any arguments that would leak that abstraction (i.e.,
arguments like stack_top/stack_bottom).
GetStackTrace will become an implementation detail (private method) of
the BufferedStackTrace class.
Reviewers: vitalybuka
Differential Revision: https://reviews.llvm.org/D58741
llvm-svn: 355168
We already independently declare GetStackTrace in all (except TSan)
sanitizer runtime headers. Lets move it to sanitizer_stacktrace.h to
have one canonical way to fill in a BufferedStackFrame. Also enables us
to use it in sanitizer_common itself.
This patch defines GetStackTrace for TSan and moves the function from
ubsan_diag.cc to ubsan_diag_standalone.cc to avoid duplicate symbols
for the UBSan-ASan runtime.
Other than that this patch just moves the code out of headers and into
the correct namespace.
Reviewers: vitalybuka
Differential Revision: https://reviews.llvm.org/D58651
llvm-svn: 355039
Also assert that the caller always gets what it requested.
This purely mechanical change simplifies future refactorings and
eventual removal of BufferedStackTrace::Unwind.
Reviewers: vitalybuka
Differential Revision: https://reviews.llvm.org/D58557
llvm-svn: 355022
Summary:
pthread_sigmask is just like sigprocmask, except that its behavior in
multithreaded programs is explicitly specified. Sanitizers were lacking
a common interceptor for pthread_sigmask (although some specific
sanitizers defined custom version), which lead to false positives
(at least in msan) when using this function.
The interceptor implementation, and its test are based on the equivalent
code for sigprocmask.
Reviewers: eugenis, vitalybuka
Subscribers: kubamracek, delcypher, jfb, jdoerfert, llvm-commits, #sanitizers
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D58382
llvm-svn: 354874
In compiler-rt we have the notion of a `fast` and a `slow` stack
unwinder. Darwin currently only supports the fast unwinder.
From reading the code, my understanding is that
`BufferedStackTrace::Unwind` can be called with `bp=0, stack_top=0,
stack_bottom=0, request_fast_unwind=false`. If
`request_fast_unwind=true`, then we alos need to supply bp, stack_top,
and stack_bottom.
However, `BufferedStackTrace::Unwind` uses
`StackTrace::WillUseFastUnwind` which will adapt `request_fast_unwind`
if the requested unwinder is not supported. On Darwin, the result is
that we don't pass actual values for bp, stack_top, and stack_bottom,
but end up using the fast unwinder. The tests then fail because we only
print the topmost stack frame.
This patch adds a check to `WillUseFastUnwind` at the point of usage to
avoid the mismatch between `request_fast_unwind` and what `Unwind`
actually does. I am also interested in cleaning up the
`request_fast_unwind` machinery so this patch just the simplest thing
possible so I can enable the tests.
Reviewers: vitalybuka, vsk
Differential Revision: https://reviews.llvm.org/D58156
llvm-svn: 354282
This patch adds functions for managing fibers:
__tsan_get_current_fiber()
__tsan_create_fiber()
__tsan_destroy_fiber()
__tsan_switch_to_fiber()
__tsan_set_fiber_name()
See the added tests for use examples.
Author: yuri (Yuri Per)
Reviewed in: https://reviews.llvm.org/D54889
[The previous commit of this change was reverted,
this is a resubmit with a squashed fix for check_analyze.sh
and COMMON_INTERCEPTOR_NOTHING_IS_INITIALIZED]
llvm-svn: 353947
buildgo.sh puts most of sanitizer_common together in a single source
file. These single-letter macros end up affecting a lot of unrelated
code; #undef them as early as possible.
llvm-svn: 353902
This patch adds functions for managing fibers:
__tsan_get_current_fiber()
__tsan_create_fiber()
__tsan_destroy_fiber()
__tsan_switch_to_fiber()
__tsan_set_fiber_name()
See the added tests for use examples.
Author: yuri (Yuri Per)
Reviewed in: https://reviews.llvm.org/D54889
llvm-svn: 353817
Summary:
Scoped interceptor should not be used when calling real pthread_exit().
On macOS C++ destructors are not called by pthread_exit(), and later check for empty thread ignore set fails.
Patch by Yuri Per.
Reviewers: dvyukov, vitalybuka
Reviewed By: vitalybuka
Subscribers: vitalybuka, thegameg, kubamracek, jfb, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D57963
llvm-svn: 353561
- Manually unwind code in MemoryAccessImpl1() because clang do not optimize it
- Check for .rodata section only in read operations
- Place LIKELY/UNLIKELY on fast paths
This speeds up synthetic memory access benchmarks by 10-20%.
[dvyukov: fixed up consts in check_analyze.sh]
Author: yuri (Yuri Per)
Reviewed in: https://reviews.llvm.org/D57882
Context: https://reviews.llvm.org/D54889
llvm-svn: 353401
Replace bool workerthread flag with ThreadType enum.
This change is preparation for fiber support.
[dvyukov: fixed build of sanitizer_thread_registry_test.cc]
Author: yuri (Yuri Per)
Reviewed in: https://reviews.llvm.org/D57839
Context: https://reviews.llvm.org/D54889
llvm-svn: 353390
Summary:
Buffer should be referenced by results so used parts will be unpoisoned with unpoison_group and unpoison_passwd.
This fixes TSAN performance issue made us to disable this interceptors.
Reviewers: eugenis, dvyukov
Subscribers: srhines, kubamracek, krytarowski, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D57731
llvm-svn: 353351
Julian Lettner