I verified that the test is red without the interceptors.
rdar://40334350
Reviewed By: kubamracek, vitalybuka
Differential Revision: https://reviews.llvm.org/D66616
llvm-svn: 371439
Rename file `tsan_libdispatch.cpp -> tsan_libdispatch_interceptors.cpp`
to make it clear that it's main purpose is defining interceptors.
llvm-svn: 369289
The xpc_connection_* APIs that we are intercepting are available
starting at macOS 10.7. This is old enough so that we don't need to
guard them.
llvm-svn: 369150
Summary:
It appears that since https://reviews.llvm.org/D54889, BackgroundThread()
crashes immediately because cur_thread()-> will return a null pointer
which is then dereferenced. I'm not sure why I only see this issue on
FreeBSD and not Linux since it should also be unintialized on other platforms.
Reviewers: yuri, dvyukov, dim, emaste
Subscribers: kubamracek, krytarowski, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D65705
llvm-svn: 368103
in madvise mode, the shadow pages will be migrated only via madvise explicit calls.
Reviewers: vitalybuka
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D65775
llvm-svn: 368090
Like r367463, but for tsan/{benchmarks,dd,go}.
The files benchmarks aren't referenced in the build anywhere and where added
in 2012 with the comment "no Makefiles yet".
llvm-svn: 367567
See https://reviews.llvm.org/D58620 for discussion, and for the commands
I ran. In addition I also ran
for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done
and manually updated (many) references to renamed files found by that.
llvm-svn: 367463
Summary:
Combine few relatively small changes into one:
- implement internal_ptrace() and internal_clone() for NetBSD
- add support for stoptheworld based on the ptrace(2) API
- define COMPILER_RT_HAS_LSAN for NetBSD
- enable tests for NetBSD/amd64
Inspired by the original implementation by Christos Zoulas in netbsd/src for GCC.
The implementation is in theory CPU independent through well defined macros
across all NetBSD ports, however only the x86_64 version was tested.
Reviewers: mgorny, dvyukov, vitalybuka, joerg, jfb
Reviewed By: vitalybuka
Subscribers: dexonsmith, jfb, srhines, kubamracek, llvm-commits, christos
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64057
llvm-svn: 365735
Fix compilation errors related to `SANITIZER_GO` `#ifdef`s.
Refine longjmp key management. For Linux, re-implement key retrieval in
C (instead of assembly). Removal of `InitializeGuardPtr` and a final
round of cleanups will be done in the next commit.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D64092
> llvm-svn: 365513
llvm-svn: 365560
Refine longjmp key management. For Linux, re-implement key retrieval in
C (instead of assembly). Removal of `InitializeGuardPtr` and a final
round of cleanups will be done in the next commit.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D64092
llvm-svn: 365513
For x86_64, since we don't clobber %rsi (2nd argument) anymore, we don't
have to save/restore it.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D63946
llvm-svn: 365229
Factor out `ExtractLongJmpSp` helper function and move platform-specific
code to tsan_platform_{linux,mac}.cc.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D64050
llvm-svn: 364947
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
Summary:
It looks like LLVM has started doing less tail duplication in this code,
or something like that, resulting in a significantly smaller number of
pop instructions (16 -> 12). Removing the check.
Reviewers: vitalybuka, dvyukov
Subscribers: kubamracek, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D63450
llvm-svn: 363615
Dmitry Vyukov