Some Darwin functions have pairs like dispatch_apply and dispatch_apply_f so the added _f to interceptor types causes a clash. Let's add _type suffix instead.
Differential Revision: https://reviews.llvm.org/D53167
llvm-svn: 344954
Summary:
The UINTMAX_T type will be used in new interceptors.
While there, correct the type of strtoumax(3) from INTMAX_T to UINTMAX_T.
Original patch from Yang Zheng.
Reviewers: vitalybuka, kcc, joerg
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, tomsun.0.7, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D51106
llvm-svn: 340907
This commit contains the trivial portion of the port of ASan to
Myriad RTEMS.
- Whitelist platform in sanitizer_platform.h, ubsan_platform.h
- Turn off general interception
- Use memset for FastPoisonShadow
- Define interception wrappers
- Set errno symbol correctly
- Enable ASAN_LOW_MEMORY
- Enable preinit array
- Disable slow unwinding
- Use fuchsia offline symbolizer
- Disable common code for: InitializeShadowMemory, CreateMainThread,
AsanThread::ThreadStart, StartReportDeadlySignal,
MaybeReportNonExecRegion.
Differential Revision: https://reviews.llvm.org/D46454
llvm-svn: 332681
Summary:
This is the first mostly working version of the Sanitizer port to 32-bit Solaris/x86.
It is currently based on Solaris 11.4 Beta.
This part was initially developed inside libsanitizer in the GCC tree and should apply to
both. Subsequent parts will address changes to clang, the compiler-rt build system
and testsuite.
I'm not yet sure what the right patch granularity is: if it's profitable to split the patch
up, I'd like to get guidance on how to do so.
Most of the changes are probably straightforward with a few exceptions:
* The Solaris syscall interface isn't stable, undocumented and can change within an
OS release. The stable interface is the libc interface, which I'm using here, if possible
using the internal _-prefixed names.
* While the patch primarily target 32-bit x86, I've left a few sparc changes in. They
cannot currently be used with clang due to a backend limitation, but have worked
fine inside the gcc tree.
* Some functions (e.g. largefile versions of functions like open64) only exist in 32-bit
Solaris, so I've introduced a separate SANITIZER_SOLARIS32 to check for that.
The patch (with the subsequent ones to be submitted shortly) was tested
on i386-pc-solaris2.11. Only a few failures remain, some of them analyzed, some
still TBD:
AddressSanitizer-i386-sunos :: TestCases/Posix/concurrent_overflow.cc
AddressSanitizer-i386-sunos :: TestCases/init-order-atexit.cc
AddressSanitizer-i386-sunos :: TestCases/log-path_test.cc
AddressSanitizer-i386-sunos :: TestCases/malloc-no-intercept.c
AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/concurrent_overflow.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/start-deactivated.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/default_options.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/init-order-atexit.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/log-path_test.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/malloc-no-intercept.c
SanitizerCommon-Unit :: ./Sanitizer-i386-Test/MemoryMappingLayout.DumpListOfModules
SanitizerCommon-Unit :: ./Sanitizer-i386-Test/SanitizerCommon.PthreadDestructorIterations
Maybe this is good enough the get the ball rolling.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, jyknight, kubamracek, krytarowski, fedor.sergeev, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40898
llvm-svn: 320740
Summary:
Unlike the rest of the sanitizer code, lib/interception uses native macros like __linux__
to check for specific targets instead of the common ones like SANITIZER_LINUX.
When working on the Solaris port of the sanitizers, the current style was found to not
only be inconsistent, but clumsy to use because the canonical way to check for Solaris
is to check for __sun__ && __svr4__ which is a mouthful.
Therefore, this patch switches to use SANITIZER_* macros instead.
Tested on x86_64-pc-linux-gnu.
Reviewers: kcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: #sanitizers, srhines, krytarowski, llvm-commits, fedor.sergeev
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D39798
llvm-svn: 319906
Fuchsia's lowest API layer has been renamed from Magenta to Zircon.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D37770
llvm-svn: 313106
Summary:
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, kcc, filcab, vitalybuka
Reviewed By: vitalybuka
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36323
llvm-svn: 310140
Summary:
Actually Fuchsia non-support for interceptors. Fuchsia doesn't use
interceptors in the common sense at all. Almost all system library
functions don't need interception at all, because the system
libraries are just themselves compiled with sanitizers enabled and
have specific hook interfaces where needed to inform the sanitizer
runtime about thread lifetimes and the like. For the few functions
that do get intercepted, they don't use a generic mechanism like
dlsym with RTLD_NEXT to find the underlying system library function.
Instead, they use specific extra symbol names published by the
system library (e.g. __unsanitized_memcpy).
Submitted on behalf of Roland McGrath.
Reviewers: vitalybuka, alekseyshl, kcc, filcab
Reviewed By: filcab
Subscribers: kubamracek, phosek, filcab, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36028
llvm-svn: 309745
The definitions in sanitizer_common may conflict with definitions from system headers because:
The runtime includes the system headers after the project headers (as per LLVM coding guidelines).
lib/sanitizer_common/sanitizer_internal_defs.h pollutes the namespace of everything defined after it, which is all/most of the sanitizer .h and .cc files and the included system headers with: using namespace __sanitizer; // NOLINT
This patch solves the problem by introducing the namespace only within the sanitizer namespaces as proposed by Dmitry.
Differential Revision: https://reviews.llvm.org/D21947
llvm-svn: 281657
Summary:
This patch is re-introducing the code to fix the
dynamic hooking on windows and to fix a compiler
warning on Apple.
Related patches:
* https://reviews.llvm.org/D22641
* https://reviews.llvm.org/D22610
* https://reviews.llvm.org/rL276311
* https://reviews.llvm.org/rL276490
Both architecture are using different techniques to
hook on library functions (memchr, strcpy,...).
On Apple, the function is not dynamically hooked and
the symbol always points to a valid function
(i.e. can't be null). The REAL macro returns the
symbol.
On windows, the function is dynamically patch and the
REAL(...) function may or may not be null. It depend
on whether or not the function was hooked correctly.
Also, on windows memcpy and memmove are the same.
```
#if !defined(__APPLE__)
[...]
# define REAL(x) __interception::PTR_TO_REAL(x)
# define ASSIGN_REAL(dst, src) REAL(dst) = REAL(src)
[...]
#else // __APPLE__
[...]
# define REAL(x) x
# define ASSIGN_REAL(x, y)
[...]
#endif // __APPLE__
Reviewers: rnk
Subscribers: kcc, hans, kubabrecka, llvm-commits, bruno, chrisha
Differential Revision: https://reviews.llvm.org/D22758
llvm-svn: 276885
ThreadLister is a Linux-specific class for obtaining the thread IDs of a process from procfs (/proc/<pid>/task/). It will be used by leak checking code.
Also add several syscall wrappers which will be required by the same code that uses ThreadLister, but are not used in ThreadLister itself.
Patch by Sergey Matveev
llvm-svn: 176179
that had been used on OS X only.
The INTERCEPTOR() macro on OS X is now responsible for declaring the wrapped function, the wrapper and the
pair of pointers to them in __DATA,__interposition section. Thus adding an interceptor requires editing a single file now.
llvm-svn: 175740
The idea isthat asan/tsan can survive if user intercepts the same functions. At the same time user has an ability to call back into asan/tsan runtime. See the following tests for examples:
asan/output_tests/interception_failure_test-linux.cc
asan/output_tests/interception_test-linux.cc
asan/output_tests/interception_malloc_test-linux.cc
llvm-svn: 157388
Kuba Mracek