ld.config.txt defines linker namespaces in a way that is incompatible
with ASan. Remove the file when installing ASan on an Android O
(8.0.x) device.
Patch by Jiyong Park.
llvm-svn: 312581
Summary:
Check sigset_t arguments in ppoll, sig*wait*, sigprocmask
interceptors, and the entire "struct sigaction" in sigaction. This
can be done because sigemptyset/sigfullset are intercepted and
signal masks should be correctly marked as initialized.
Reviewers: vitalybuka
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D37367
llvm-svn: 312576
Breaks buildbot with
CMake Error at projects/compiler-rt/test/CMakeLists.txt:76 (add_dependencies):
The dependency target "check-ubsan-minimal" of target "check-ubsan" does
not exist.
llvm-svn: 312295
Summary: This way we don't need to add check-ubsan-minimal steps to all the bots.
Reviewers: vitalybuka
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D37350
llvm-svn: 312291
The buildbots have shown that -Wstrict-prototypes behaves differently in GCC
and Clang so we should keep it disabled until Clang follows GCC's behaviour
llvm-svn: 312246
Clang 5 supports -Wstrict-prototypes. We should use it to catch any C
declarations that declare a non-prototype function.
rdar://33705313
Differential Revision: https://reviews.llvm.org/D36669
llvm-svn: 312240
Summary:
Before this change we seemed to not be running the unit tests, and therefore we
set out to run them. In the process of making this happen we found a divergence
between the implementation and the tests.
This includes changes to both the CMake files as well as the implementation and
headers of the XRay runtime. We've also updated documentation on the changed
functions.
Reviewers: kpw, eizan
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D37290
llvm-svn: 312202
Summary:
This code already works and passes some number of tests.
There is need to finish remaining sanitizers to get better coverage.
Many tests fail due to overly long file names of executables (>31).
This is a current shortcoming of the NetBSD 8(beta) kernel, as
certain functions can fail (like retrieving file name of executable).
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, kcc, vitalybuka, george.karpenkov
Reviewed By: kcc
Subscribers: mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D37304
llvm-svn: 312183
Summary:
A snipped from the documentation of thread_setname_np(3):
NAME
pthread_getname_np - get and set descriptive name of a thread
LIBRARY
POSIX Threads Library (libpthread, -lpthread)
SYNOPSIS
#include <pthread.h>
int
pthread_getname_np(pthread_t thread, char *name, size_t len);
int
pthread_setname_np(pthread_t thread, const char *name, void *arg);
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, dvyukov, eugenis, vitalybuka, kcc
Reviewed By: dvyukov
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D37306
llvm-svn: 312159
Summary:
Some architecture-specific function overrides (for example, i386/ashrdi3.S)
duplicate generic functions (in that case, ashrdi3.c). Prevent duplicate definitions
by filtering out the generic files before compiling.
Reviewers: compnerd, beanz
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D37166
llvm-svn: 312140
Summary:
Recent changes canonicalized clang_rt library names to refer to
"i386" on all x86 targets. Android historically uses i686.
This change adds a special case to keep i686 in all clang_rt
libraries when targeting Android.
Reviewers: hans, mgorny, beanz
Subscribers: srhines, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D37278
llvm-svn: 312048
Summary: Adds a true implementation of GetRandom, to be used by scudo_utils.h.
Reviewers: mcgrathr, phosek, kcc, vitalybuka, cryptoad
Reviewed By: mcgrathr
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D37218
llvm-svn: 312046
Summary:
An implementation of ubsan runtime library suitable for use in production.
Minimal attack surface.
* No stack traces.
* Definitely no C++ demangling.
* No UBSAN_OPTIONS=log_file=/path (very suid-unfriendly). And no UBSAN_OPTIONS in general.
* as simple as possible
Minimal CPU and RAM overhead.
* Source locations unnecessary in the presence of (split) debug info.
* Values and types (as in A+B overflows T) can be reconstructed from register/stack dumps, once you know what type of error you are looking at.
* above two items save 3% binary size.
When UBSan is used with -ftrap-function=abort, sometimes it is hard to reason about failures. This library replaces abort with a slightly more informative message without much extra overhead. Since ubsan interface in not stable, this code must reside in compiler-rt.
Reviewers: pcc, kcc
Subscribers: srhines, mgorny, aprantl, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D36810
llvm-svn: 312029
Summary:
This change hides all the initialization of thread_local variables used
by the XRay FDR mode implementation behind a function call. This makes
initialization of thread-local data to be done lazily, instead of
eagerly when they're done as globals. It also gives us an isolation
mechanism if/when we want to change the TLS implementation from using
the C++ thread_local keyword, for something more ad-hoc (potentialy
using pthread directly) on some platforms or set-ups where we cannot use
the C++ thread_local variables.
Reviewers: kpw, eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37248
llvm-svn: 311997
Summary:
The NetBSD's 8(beta) versions of kernel functions to retrieve
program name (vnode to path translator) and process memory
map have internal limit of processing filenames with maximum
of 31 characters.
Filenames like Asan-x86_64-with-calls-Noinst-Test break this
limit and affect tests. Rename "-with-calls" to "-calls".
This changes fixes all issues for the Address Sanitizer test
target (check-asan) on the current NetBSD support caused
by long filenames.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, filcab, fjricci, kcc
Reviewed By: vitalybuka
Subscribers: kubamracek, mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D37149
llvm-svn: 311966
Summary:
NetBSD is an Open-Source POSIX-like BSD Operating System.
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, vitalybuka, filcab, fjricci
Reviewed By: kcc
Subscribers: llvm-commits, kubamracek, mgorny, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D37193
llvm-svn: 311933
Remove the explicit i686 target that is completely duplicate to
the i386 target, with the latter being used more commonly.
1. The runtime built for i686 will be identical to the one built for
i386.
2. Supporting both -i386 and -i686 suffixes causes unnecessary confusion
on the clang end which has to expect either of them.
3. The checks are based on wrong assumption that __i686__ is defined for
all newer x86 CPUs. In fact, it is only declared when -march=i686 is
explicitly used. It is not available when a more specific (or newer)
-march is used.
Curious enough, if CFLAGS contain -march=i686, the runtime will be built
both for i386 and i686. For any other value, only i386 variant will be
built.
Differential Revision: https://reviews.llvm.org/D26764
llvm-svn: 311924
Under the previous configurations, flags from SANITIZER_COMMON were not
propagated for standalone builds.
Differential Revision: https://reviews.llvm.org/D37225
llvm-svn: 311912
- Not having a dependency does not work in standalone build, as Clang does not exist.
- if (TARGET clang) check is useless, as it is order-dependent,
and Clang may not be registered yet.
Differential Revision: https://reviews.llvm.org/D37228
llvm-svn: 311911
Summary:
Currently `TransferBatch` are located within the same memory regions as
"regular" chunks. This is not ideal for security: they make for an interesting
target to overwrite, and are not protected by the frontend (namely, Scudo).
To solve this, we re-introduce `kUseSeparateSizeClassForBatch` for the 32-bit
Primary allowing for `TransferBatch` to end up in their own memory region.
Currently only Scudo would use this new feature, the default behavior remains
unchanged. The separate `kBatchClassID` was used for a brief period of time
previously but removed when the 64-bit ended up using the "free array".
Reviewers: alekseyshl, kcc, eugenis
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D37082
llvm-svn: 311891
Summary:
XRay has erroneously been returning the address of the first sled in the
instrumentation map for a function id instead of the (runtime-relocated)
functison address. This causes confusion and issues for applications
where:
- The first sled in the function may not be an entry sled (due to
re-ordering or some other reason).
- The caller attempts to find a symbol associated with the pointer at
runtime, because the sled may not be exactly where the function's
known address is (in case of inlined functions or those that have an
external definition for symbols).
This fixes http://llvm.org/PR34340.
Reviewers: eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37202
llvm-svn: 311871
Heretofore asan_handle_no_return was used only by interceptors,
i.e. code private to the ASan runtime. However, on systems without
interceptors, code like libc++abi is built with -fsanitize=address
itself and should call asan_handle_no_return directly from
__cxa_throw so that no interceptor is required.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D36811
llvm-svn: 311869
Remove the explicit i686 target that is completely duplicate to
the i386 target, with the latter being used more commonly.
1. The runtime built for i686 will be identical to the one built for
i386.
2. Supporting both -i386 and -i686 suffixes causes unnecessary confusion
on the clang end which has to expect either of them.
3. The checks are based on wrong assumption that __i686__ is defined for
all newer x86 CPUs. In fact, it is only declared when -march=i686 is
explicitly used. It is not available when a more specific (or newer)
-march is used.
Curious enough, if CFLAGS contain -march=i686, the runtime will be built
both for i386 and i686. For any other value, only i386 variant will be
built.
Differential Revision: https://reviews.llvm.org/D26764
llvm-svn: 311842
Change the default of COMPILER_RT_SANITIZERS_TO_BUILD to "all" in
order to automatically pick up new sanitizers in existing build
trees.
llvm-svn: 311824
The problem is that CMake is mostly imperative and the result of
processing "if (TARGET blah)" checks depends on the order of import of
CMake files.
In this case, "projects" folder is registered before "tools",
and calling "CheckClangHeaders" [renamed to have a better name]
errors out without even giving Clang a chance to be built.
This, in turn, leads to libFuzzer bot failures in some circumstances on
some machines (depends on whether LIT or UNIT tests are scheduled
first).
Differential Revision: https://reviews.llvm.org/D37126
llvm-svn: 311733
Summary:
This is a patch for PR34167.
On HF targets functions like `__{eq,lt,le,ge,gt}df2` and `__{eq,lt,le,ge,gt}sf2` expect their arguments to be passed in d/s registers, while some of the AEABI builtins pass them in r registers.
Reviewers: compnerd, peter.smith, asl
Reviewed By: peter.smith, asl
Subscribers: peter.smith, aemerson, dberris, javed.absar, llvm-commits, asl, kristof.beyls
Differential Revision: https://reviews.llvm.org/D36675
llvm-svn: 311555
Summary:
This change introduces versions to the instrumentation map entries we
emit for XRay instrumentaiton points. The status quo for the version is
currently set to 0 (as emitted by the LLVM back-end), and versions will
count up to 255 (unsigned char).
This change is in preparation for supporting the newer version of the
custom event sleds that will be emitted by the LLVM compiler.
While we're here, we take the opportunity to stash more registers and
align the stack properly in the __xray_CustomEvent trampoline.
Reviewers: kpw, pcc, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36816
llvm-svn: 311524
The struct tag is going away in soon-to-be-released glibc 2.26 and the
stack_t typedef seems to have been there forever.
Patch by Bernhard Rosenkraenzer!
llvm-svn: 311495
Summary:
Use the initialexec TLS type and eliminate calls to the TLS
wrapper. Fixes the sanitizer-x86_64-linux-fuzzer bot failure.
Reviewers: vitalybuka, kcc
Reviewed By: kcc
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D37026
llvm-svn: 311490
This reverts SVN r311425 which broke one of the buildbots. It is
unclear what header is being used there. Revert it until that can be
handled properly.
llvm-svn: 311426
On ARM, the `_Unwind_Exception` is an alias for
`struct _Unwind_Control_Block`. The extra `struct` modifier causes a
warning due to the locally scoped type. Special case this to avoid the
warning. NFC.
llvm-svn: 311425
Resulting library binaries will be named libclang_rt.fuzzer*, and will
be placed in Clang toolchain, allowing redistribution.
Differential Revision: https://reviews.llvm.org/D36908
llvm-svn: 311407
Summary:
String flags values appear to be duped twice. Once in `FlagParser::parse_flag`
using the `LowLevelAllocator` via `ll_strndup`, once in
`FlagHandler<const char *>::Parse` using the `InternalAllocator` via
`internal_strdup`. It looks like the second one is redundant, as the memory
for the first one is never freed and not used for anything else.
Assigning the value to the flag instead of duping it has a few advantages:
- if it was the only use of the `InternalAllocator` (which is the case for
Scudo), then the related code will not be compiled it, which saves us a
whole instantiation of the CombinedAllocator worth of extra code;
- in the event a string flag is parsed, the `InternalAllocator` would have
created a whole SizeClassAllocator32 region for a single allocation, which is
kind of wasteful.
- also, the string is dup'ed twice for the whole lifetime of a process.
I tested check-{sanitizer,asan,tsan,ubsan,scudo} successfully, so as far as I
can tell this doesn't appear to have bad side effects.
Reviewers: eugenis, alekseyshl
Reviewed By: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D36970
llvm-svn: 311386
CMake's add_custom_target is considered to be *always* out of date.
This patch changes it to a combination of add_custom_target and
add_custom_command which actually tracks dependencies' timestamps.
On my machine this reliably saves 6-7 seconds on each test group.
This can be a large difference when debugging small tests.
Differential Revision: https://reviews.llvm.org/D36912
llvm-svn: 311384
Summary:
This test was broken by the tail duplication logic being changed in
r311139, update the test values and add a note about how to properly run
a benchmark to verify that the values are safe to update.
Reviewers: vitalybuka
Reviewed By: vitalybuka
Subscribers: dvyukov, kubamracek
Differential Revision: https://reviews.llvm.org/D36889
llvm-svn: 311189
Summary:
Augment SanitizerCoverage to insert maximum stack depth tracing for
use by libFuzzer. The new instrumentation is enabled by the flag
-fsanitize-coverage=stack-depth and is compatible with the existing
trace-pc-guard coverage. The user must also declare the following
global variable in their code:
thread_local uintptr_t __sancov_lowest_stack
https://bugs.llvm.org/show_bug.cgi?id=33857
Reviewers: vitalybuka, kcc
Reviewed By: vitalybuka
Subscribers: kubamracek, hiraditya, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D36839
llvm-svn: 311186
Summary:
Here we add a build with -ffunction-sections -fdata-sections and
-Wl,--gc-sections to ensure that we're still able to generate XRay
traces.
This is just adding a test, no functional changes.
Differential Revision: https://reviews.llvm.org/D36863
llvm-svn: 311145
Summary:
This patch changes a few (small) things around for compatibility purposes for
the current Android & Fuchsia work:
- `realloc`'ing some memory that was not allocated with `malloc`, `calloc` or
`realloc`, while UB according to http://pubs.opengroup.org/onlinepubs/009695399/functions/realloc.html
is more common that one would think. We now only check this if
`DeallocationTypeMismatch` is set; change the "mismatch" error
messages to be more homogeneous;
- some sketchily written but widely used libraries expect a call to `realloc`
to copy the usable size of the old chunk to the new one instead of the
requested size. We have to begrundingly abide by this de-facto standard.
This doesn't seem to impact security either way, unless someone comes up with
something we didn't think about;
- the CRC32 intrinsics for 64-bit take a 64-bit first argument. This is
misleading as the upper 32 bits end up being ignored. This was also raising
`-Wconversion` errors. Change things to take a `u32` as first argument.
This also means we were (and are) only using 32 bits of the Cookie - not a
big thing, but worth mentioning.
- Includes-wise: prefer `stddef.h` to `cstddef`, move `scudo_flags.h` where it
is actually needed.
- Add tests for the memalign-realloc case, and the realloc-usable-size one.
(Edited typos)
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36754
llvm-svn: 311018
into a function.
Most CMake configuration under compiler-rt/lib/*/tests have
almost-the-same-but-not-quite functions of the form add_X_[unit]tests
for compiling and running the tests.
Much of the logic is duplicated with minor variations across different
sub-folders.
This can harm productivity for multiple reasons:
For newcomers, resulting CMake files are very large, hard to understand,
and hide the intention of the code.
Changes for enabling certain architectures end up being unnecessarily
large, as they get duplicated across multiple folders.
Adding new sub-projects requires more effort than it should, as a
developer has to again copy-n-paste the configuration, and it's not even
clear from which sub-project it should be copy-n-pasted.
With this change the logic of compile-and-generate-a-set-of-tests is
extracted into a function, which hopefully makes writing and reading
CMake much easier.
Differential Revision: https://reviews.llvm.org/D36116
llvm-svn: 310971
Detect ObjC files in `clang_compile` and pass an appropriate flag to a
compiler, also change `clang_compile` to a function.
Differential Revision: https://reviews.llvm.org/D36727
llvm-svn: 310945
Change macro to a function, and use a generic variable instead of
branching for handling multi-output build with
CMAKE_CONFIGURATION_TYPES.
Differential Revision: https://reviews.llvm.org/D36725
llvm-svn: 310944
Change macro to a function, move creating test directory into
`add_compiler_rt_test`.
Differential Revision: https://reviews.llvm.org/D36724
llvm-svn: 310943
Summary:
Value of __ARM_ARCH_ISA_THUMB isn't based on the actual compilation
mode (-mthumb, -marm), it reflect's capability of given CPU.
Due to this:
•use tbumb and thumb2 insteand of __ARM_ARCH_ISA_THUMB
•use '.thumb' directive consistently in all affected files
•decorate all thumb functions using DEFINE_COMPILERRT_THUMB_FUNCTION()
(This is based off Michal's patch https://reviews.llvm.org/D30938)
Reviewers: dim, rengolin, compnerd, strejda
Reviewed By: compnerd
Subscribers: peter.smith, kubamracek, mgorny, javed.absar, kristof.beyls, jamesduley, aemerson, llvm-commits
Differential Revision: https://reviews.llvm.org/D31220
llvm-svn: 310884
Summary:
On platforms with `getrandom`, the system call defaults to blocking. This
becomes an issue in the very early stage of the boot for Scudo, when the RNG
source is not set-up yet: the syscall will block and we'll stall.
Introduce a parameter to specify that the function should not block, defaulting
to blocking as the underlying syscall does.
Update Scudo to use the non-blocking version.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D36399
llvm-svn: 310839
Summary: This is to support Android where libc++abi is part of libc++.
Reviewers: srhines, EricWF
Subscribers: dberris, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D36640
llvm-svn: 310769
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: fjricci, vitalybuka, joerg, kcc, filcab
Reviewed By: vitalybuka
Subscribers: llvm-commits, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36488
llvm-svn: 310647
Added declarations of __sanitizer_cov_trace_const_cmp[1248] callbacks.
For more details, please see https://reviews.llvm.org/D36465.
Patch by Victor Chibotaru.
llvm-svn: 310596
Summary:
Similarly to i686, the ARM build target has multiple names, such as armhf, armv7 and so on. Currently we get duplicated symbol definitions for these targets while compiling the library. Each duplicated definition has its generic version from `lib/builtins` and an ARM-specialized version from `lib/builtins/arm`.
This patch fixes filtering for ARM to ignore the generic definitions if they have their ARM specializations.
Reviewers: compnerd
Reviewed By: compnerd
Subscribers: aemerson, dberris, llvm-commits, mgorny, asl, kristof.beyls
Differential Revision: https://reviews.llvm.org/D35336
llvm-svn: 310588
Summary:
This is a pure refactoring change. It paves the way for OS-specific
implementations, such as Fuchsia's, that can do most of the
per-thread bookkeeping work in the creator thread before the new
thread actually starts. This model is simpler and cleaner, avoiding
some race issues that the interceptor code for thread creation has
to do for the existing OS-specific implementations.
Submitted on behalf of Roland McGrath.
Reviewers: vitalybuka, alekseyshl, kcc
Reviewed By: alekseyshl
Subscribers: phosek, filcab, llvm-commits, kubamracek
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36385
llvm-svn: 310432
The 9 byte nop is a suffix of the 10 byte nop, and we need at most 6
bytes.
ntdll's version of strcpy is written in assembly and is very clever.
strcat tail calls strcpy but with a slightly different arrangement of
argument registers at an alternate entry point. It looks like this:
ntdll!strcpy:
00007ffd`64e8a7a0 4c8bd9 mov r11,rcx
ntdll!__entry_from_strcat_in_strcpy:
00007ffd`64e8a7a3 482bca sub rcx,rdx
00007ffd`64e8a7a6 f6c207 test dl,7
If we overwrite more than two bytes in our interceptor, that label will
no longer be a valid instruction boundary.
By recognizing the 9 byte nop, we use the two byte backwards branch to
start our trampoline, avoiding this issue.
Fixes https://github.com/google/sanitizers/issues/829
Patch by David Major
llvm-svn: 310419
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, fjricci, vitalybuka, filcab
Reviewed By: fjricci
Subscribers: llvm-commits, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36376
llvm-svn: 310414
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, filcab, vitalybuka, kcc, fjricci
Reviewed By: fjricci
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36484
llvm-svn: 310413
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, vitalybuka, kcc, filcab, fjricci
Reviewed By: fjricci
Subscribers: srhines, kubamracek, mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36483
llvm-svn: 310412
Summary:
Follow FreeBSD and reuse sanitizer_linux for NetBSD.
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, fjricci, dvyukov
Reviewed By: fjricci
Subscribers: dvyukov, emaste, kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36325
llvm-svn: 310411
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, vitalybuka, filcab, fjricci
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36470
llvm-svn: 310400
Summary:
Do not include <malloc.h> on NetBSD, as this header
serves on this OS backward compatibility with K&R alias
for <stdlib.h>.
Sponsored by <The NetBSD Foundation>
Reviewers: vitalybuka, kcc, joerg, filcab, fjricci
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36469
llvm-svn: 310391
Summary:
Temporarily keep disabled COMPILER_RT_HAS_ASAN on NetBSD.
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, filcab, kcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, mgorny, #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36312
llvm-svn: 310370
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, vitalybuka, filcab
Reviewed By: vitalybuka
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36321
llvm-svn: 310351
Summary:
All 32 and 64 bit NetBSD platforms define off_t as 64-bit integer.
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, filcab, kcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: emaste, kubamracek, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35553
llvm-svn: 310349
Summary:
r310244 fixed a bug introduced by r309914 for non-Fuchsia builds.
In doing so it also reversed the intended effect of the change for
Fuchsia builds, which was to allow all the AllocateFromLocalPool
code and its variables to be optimized away entirely.
This change restores that optimization for Fuchsia builds, but
doesn't have the original change's bug because the comparison
arithmetic now takes into account the size of the elements.
Submitted on behalf of Roland McGrath.
Reviewers: vitalybuka, alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36430
llvm-svn: 310330
Summary:
Include <stdarg.h> for variable argument list macros (va_list, va_start etc).
Add fallback definition of _LIBCPP_GET_C_LOCALE, this is required for
GNU libstdc++ compatibility. Define new macro SANITIZER_GET_C_LOCALE.
This value is currently required for FreeBSD and NetBSD for printf_l(3) tests.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, kcc, vitalybuka, filcab, fjricci
Reviewed By: vitalybuka
Subscribers: llvm-commits, emaste, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36406
llvm-svn: 310323
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, vitalybuka, filcab, fjricci
Reviewed By: vitalybuka
Subscribers: davide, kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36377
llvm-svn: 310322
Using task_for_pid to get the "self" task is not necessary, and it can fail (e.g. for sandboxed processes). Let's just use mach_task_self().
Differential Revision: https://reviews.llvm.org/D36284
llvm-svn: 310271
Summary:
NetBSD ships with printf_l(3) like FreeBSD.
NetBSD does not ship with memalign, pvalloc, malloc with "usable size"
and is the same here as Darwin, Android, FreeBSD and Windows.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, kcc, fjricci, filcab
Reviewed By: vitalybuka
Subscribers: srhines, llvm-commits, emaste, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36373
llvm-svn: 310248
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, fjricci, vitalybuka, filcab, kcc
Reviewed By: vitalybuka
Subscribers: llvm-commits, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36374
llvm-svn: 310247
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, filcab, kcc, fjricci, vitalybuka
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36375
llvm-svn: 310246
Summary:
NetBSD ships with __errno (value for __errno_location) like Android.
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, vitalybuka, fjricci, kcc, filcab
Reviewed By: vitalybuka
Subscribers: llvm-commits, srhines, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36360
llvm-svn: 310182
Summary:
NetBSD is a POSIX-like and BSD-family system.
Reuse FreeBSD and Linux code.
NetBSD uses DWARF ExceptionHandler.
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: srhines, emaste, llvm-commits, kubamracek, aprantl, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36314
llvm-svn: 310179
Summary:
When possible reuse FreeBSD and Linux code.
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, vitalybuka, filcab
Reviewed By: vitalybuka
Subscribers: srhines, emaste, kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36320
llvm-svn: 310143
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:
This adds:
- NetBSD specific aliases for renamed syscalls,
- differentiate internal_syscall, internal_syscall64, internal_syscall_ptr as there are various types of syscalls on NetBSD.
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, vitalybuka, filcab
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36316
llvm-svn: 310139
Summary:
`pvalloc` appears to not be available on Android. Mark the failing test as
unsupported on that platform.
Reviewers: alekseyshl, vitalybuka
Reviewed By: alekseyshl, vitalybuka
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D36339
llvm-svn: 310133
Summary:
Last one of the `pvalloc` overflow checks!
`CheckForPvallocOverflow` was introduced with D35818 to detect when `pvalloc`
would wrap when rounding up to the next multiple of the page size.
Add this check to ASan's `pvalloc` implementation.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D36257
llvm-svn: 310119
Summary:
This adds NetBSD specific:
- ReadProcMaps()
- MemoryMappingLayout::Next()
This code is largely shared with FreeBSD.
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: kcc, joerg, filcab, vitalybuka, fjricci
Reviewed By: fjricci
Subscribers: emaste, kubamracek, mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35551
llvm-svn: 310116
Summary:
The regular expression to match STL allocators can't easily account for
C++ mangling compression and fails to match some valid instances of STL
allocators. Perform this logic in clang instead.
Motivated by crbug.com/751385.
Reviewers: pcc, kcc, llvm-commits
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D36291
llvm-svn: 310109
This fixes a bug in the ReadFromSymbolizer method of the
Addr2LineProcess class; if the input is too large, the returned buffer
will be null and will consequently fail the CHECK. The proposed fix is
to simply check if the buffer consists of only a null-terminator and
return if so (in effect skipping that frame). I tested by running one of
the unit tests both before and after my change.
Submitted on behalf of david-y-lam.
Reviewers: eugenis, alekseyshl, kcc
Reviewed By: alekseyshl
Differential Revision: https://reviews.llvm.org/D36207
llvm-svn: 310089
The test was not passing on targets where allocator_may_return_null
defaults to true. Change the test to a lit test so that we can test both
situations.
Patch by Kostya Kortchinsky!
Differential Revision: https://reviews.llvm.org/D36302
llvm-svn: 310033
Tested on MSVC 2013, 2015 and 2017 targeting X86, X64 and ARM.
This fixes building emutls.c for Windows for ARM (both with clang
which don't need these atomics fallbacks at all, but just failed
due to the immintrin.h include before, and with MSVC).
Differential Revision: https://reviews.llvm.org/D36071
llvm-svn: 309974
Summary:
Define a build-time configuration option for the XRay runtime to
determine whether the archive will add an entry to the `.preinit_array`
section of the binary. We also allow for initializing the XRay data
structures with an explicit call to __xray_init(). This allows us to
give users the capability to initialize the XRay data structures on
demand.
This can allow us to start porting XRay to platforms where
`.preinit_array` isn't a supported section. It also allows us to limit
the effects of XRay in the initialization sequence for applications that
are sensitive to this kind of interference (i.e. large binaries) or
those that want to package XRay control in libraries.
Future changes should allow us to build two different library archives
for the XRay runtime, and allow clang users to determine which version
to link.
Reviewers: dblaikie, kpw, pelikan
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D36080
llvm-svn: 309909
Summary:
`CheckForPvallocOverflow` was introduced with D35818 to detect when pvalloc
would wrap when rounding up to the next multiple of the page size.
Add this check to TSan's pvalloc implementation.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D36245
llvm-svn: 309897
Summary:
CheckForPvallocOverflow was introduced with D35818 to detect when pvalloc
would wrap when rounding up to the next multiple of the page size.
Add this check to MSan's pvalloc implementation.
This time I made sure I was actually running (and writing) the correct tests,
and that they are passing...
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36164
llvm-svn: 309883
This reverts commit r309042, thereby adding a test for -fsanitize=vptr
functionality without -fsanitize=null. It also removes -fsanitize=null
from another -fsanitize=vptr test.
llvm-svn: 309847
Summary:
Fuchsia uses the "memintrinsics" interceptors, though not via any
generalized interception mechanism. It doesn't use any other interceptors.
Submitted on behalf of Roland McGrath.
Reviewers: vitalybuka, alekseyshl, kcc
Reviewed By: vitalybuka
Subscribers: kubamracek, phosek, filcab, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36189
llvm-svn: 309798
Summary:
This change attempts to remove all the dependencies we have on
std::mutex and any std::shared_ptr construction in global variables. We
instead use raw pointers to these objects, and construct them on the
heap. In cases where it's possible, we lazily initialize these pointers.
While we do not have a replacement for std::shared_ptr yet in
compiler-rt, we use this work-around to avoid having to statically
initialize the objects as globals. Subsequent changes should allow us to
completely remove our dependency on std::shared_ptr and instead have our
own implementation of the std::shared_ptr and std::weak_ptr semantics
(or completely rewrite the implementaton to not need these
standard-library provided abstractions).
Reviewers: dblaikie, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36078
llvm-svn: 309792
Summary:
Fuchsia doesn't support built-in symbolization per se at all.
Instead, it always emits a Fuchsia-standard "symbolizer markup"
format that makes it possible for a post-processing filter to
massage the logs into symbolized format. Hence, it does not
support user-specified formatting options for backtraces or other
symbolization.
Reviewers: vitalybuka, alekseyshl, kcc
Subscribers: kubamracek, mgorny, phosek, filcab, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36032
llvm-svn: 309760
Summary:
Fuchsia doesn't support filesystem access per se at low level.
So it won't use any of the filesystem-oriented code in sanitizer_common.
Submitted on behalf of Roland McGrath.
Reviewers: vitalybuka, alekseyshl, kcc
Reviewed By: vitalybuka
Subscribers: kubamracek, phosek, filcab, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36029
llvm-svn: 309749
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
Android uses libgcc name even for shared library unlike other platforms
which use libgcc_s. Furthemore, Android libstdc++ has a dependency on
libdl. These need to be handled while performing CMake checks.
Differential Revision: https://reviews.llvm.org/D36035
llvm-svn: 309638
Summary:
Reverting D36093 until I can figure out how to launch the correct tests :/
My apologies.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36120
llvm-svn: 309637
Summary:
`CheckForPvallocOverflow` was introduced with D35818 to detect when pvalloc
would wrap when rounding up to the next multiple of the page size.
Add this check to MSan's pvalloc implementation.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36093
llvm-svn: 309601
Summary: More changes to follow will add the Fuchsia port.
Submitted on behalf of Roland McGrath.
Reviewers: vitalybuka, alekseyshl, kcc
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, phosek, filcab
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36027
llvm-svn: 309539
The quiet-start.cc test currently fails for arm (and potentially other
platforms). This change limits it to x86_64-linux.
Follow-up to D35789.
llvm-svn: 309538
Lowercase the Windows.h include in enable_execute_stack.c, just as in
emutls.c in SVN r302340.
Differential Revision: https://reviews.llvm.org/D36066
llvm-svn: 309537
Summary:
New systems might be neither Windows nor POSIX. The SI_NOT_WINDOWS
macro in sanitizer_platform_interceptors.h was already effectively
the same as SI_POSIX, so just use SI_POSIX instead.
Submitted on behalf of Roland McGrath.
Reviewers: vitalybuka, alekseyshl, kcc
Reviewed By: vitalybuka
Subscribers: phosek, filcab, llvm-commits, kubamracek
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36038
llvm-svn: 309536
Summary:
Currently when the XRay runtime is linked into a binary that doesn't
have the instrumentation map, we print a warning unconditionally. This
change attempts to make this behaviour more quiet.
Reviewers: kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35789
llvm-svn: 309534
Summary:
Included is one test for passing structs by value and one test for
passing C++
objects by value.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34827
llvm-svn: 309424
TSan tests on Darwin first link all libraries into a static archive file.
With this change, the linking is done once per all architecture,
and previously the linking step was repeated per each architecture per
each add_tsan_test call.
Furthermore, the code is cleared up.
Differential Revision: https://reviews.llvm.org/D35913
llvm-svn: 309406
Currently there's a large amount of CMake logic duplication for
compiling sanitizer tests.
If we add more sanitizers, the duplication will get even worse.
This change factors out common compilation commands into a macro
available to all sanitizers.
llvm-svn: 309405
Summary: In the current implementation, the defaul number of values per site tracked by value profiler is 8, which is too small and could introduce inaccuracies to profile. Changing it to 16 will be able to gain more accurate value profiler.
Reviewers: davidxl, tejohnson
Reviewed By: tejohnson
Subscribers: sanjoy, llvm-commits
Differential Revision: https://reviews.llvm.org/D35964
llvm-svn: 309388
This change adds sanitizer support for LLVM's libunwind and libc++abi
as an alternative to libstdc++. This allows using the in tree version
of libunwind and libc++abi which is useful when building a toolchain
for different target.
Differential Revision: https://reviews.llvm.org/D34501
llvm-svn: 309362
This change adds support for compiler-rt builtins as an alternative
compiler runtime to libgcc.
Differential Revision: https://reviews.llvm.org/D35165
llvm-svn: 309361
This patch addresses two issues:
Most of the time, hacks with `if/else` in order to get support for
multi-configuration builds are superfluous.
The variable `CMAKE_CFG_INTDIR` was created precisely for this purpose: it
expands to `.` on all single-configuration builds, and to a configuration
name otherwise.
The `if/else` hacks for the library name generation should also not be
done, as CMake has `TARGET_FILE` generator expression precisely for this
purpose, as it expands to the exact filename of the resulting target.
Differential Revision: https://reviews.llvm.org/D35952
llvm-svn: 309341
This patch addresses two issues:
Most of the time, hacks with `if/else` in order to get support for
multi-configuration builds are superfluous.
The variable `CMAKE_CFG_INTDIR` was created precisely for this purpose: it
expands to `.` on all single-configuration builds, and to a configuration
name otherwise.
The `if/else` hacks for the library name generation should also not be
done, as CMake has `TARGET_FILE` generator expression precisely for this
purpose, as it expands to the exact filename of the resulting target.
Differential Revision: https://reviews.llvm.org/D35952
llvm-svn: 309306
This change adds sanitizer support for LLVM's libunwind and libc++abi
as an alternative to libstdc++. This allows using the in tree version
of libunwind and libc++abi which is useful when building a toolchain
for different target.
Differential Revision: https://reviews.llvm.org/D34501
llvm-svn: 309074
This change adds support for compiler-rt builtins as an alternative
compiler runtime to libgcc.
Differential Revision: https://reviews.llvm.org/D35165
llvm-svn: 309060
Summary:
Previously we were rounding up the size passed to `pvalloc` to the next
multiple of page size no matter what. There is an overflow possibility that
wasn't accounted for. So now, return null in the event of an overflow. The man
page doesn't seem to indicate the errno to set in this particular situation,
but the glibc unit tests go for ENOMEM (https://code.woboq.org/userspace/glibc/malloc/tst-pvalloc.c.html#54)
so we'll do the same.
Update the aligned allocation funtions tests to check for properly aligned
returned pointers, and the `pvalloc` corner cases.
@alekseyshl: do you want me to do the same in the other Sanitizers?
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek, alekseyshl, llvm-commits
Differential Revision: https://reviews.llvm.org/D35818
llvm-svn: 309033
Summary:
__DATA segments on Darwin contain a large number of separate sections,
many of which cannot actually contain pointers, and contain const values or
objc metadata. Not scanning sections which cannot contain pointers significantly
improves performance.
On a medium-sized (~4000 files) internal project, I saw a speedup of about 30%
in standalone LSan's execution time (30% improvement in the time spent running
LSan, not the total program time).
Reviewers: kcc, kubamracek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35432
llvm-svn: 308999
Summary:
This is a re-upload of the reverted commit r308644. It has changed quite
a bit to reflect post-commit comments by kcc, so I'm re-uploading as
a new review.
Reviewers: kubamracek, alekseyshl, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35799
llvm-svn: 308977
During testing .pyc temporary files appear, which may be annoying.
Did not change SVN ignore, as it was heavily out of sync with GIT one.
Differential Revision: D35815
llvm-svn: 308931
Summary:
Set proper errno code on allocation failures and change realloc, pvalloc,
aligned_alloc, memalign and posix_memalign implementation to satisfy
their man-specified requirements.
Modify allocator API implementation to bring it closer to other
sanitizers allocators.
Reviewers: dvyukov
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D35690
llvm-svn: 308929
Summary:
Using asm works fine for gnu11, but fails if the compiler uses C11.
Switch to the more consistent __asm__, since that is what the rest of
the source is using.
Reviewers: petarj
Reviewed By: petarj
Subscribers: llvm-commits, sdardis, arichardson, pirama
Differential Revision: https://reviews.llvm.org/D35756
llvm-svn: 308922
atos is the default symbolizer on Apple's compiler for quite a few years now.
llvm-symbolizer is quite fragile on Darwin: for example, unless a .dSYM
file was explicitly generated symbolication would not work.
It is also very convenient when the behavior of LLVM open source
compiler matches to that of Apple's compiler on Apple's platform.
Furthermore, llvm-symbolizer is not installed on Apple's platform by
default, which leads to strange behavior during debugging: the test
might fail under lit (where it has llvm-symbolizer) but would run
properly when launched on the command line (where it does not, and atos
would be used).
Indeed, there's a downside: atos does not work properly with inlined
functions, hence the test change.
We do not think that this is a major problem, as users would often
compile with -O0 when debugging, and in any case it is preferable to
symbolizer not being able to symbolize.
Differential Revision: https://reviews.llvm.org/D35745
llvm-svn: 308908
Summary:
Warm-up the other 2 sizes used by the tests, which should get rid of a failure
on AArch64.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: aemerson, rengolin, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D35806
llvm-svn: 308907
Summary:
First, some context.
The main feedback we get about the quarantine is that it's too memory hungry.
A single MB of quarantine will have an impact of 3 to 4MB of PSS/RSS, and
things quickly get out of hand in terms of memory usage, and the quarantine
ends up disabled.
The main objective of the quarantine is to protect from use-after-free
exploitation by making it harder for an attacker to reallocate a controlled
chunk in place of the targeted freed chunk. This is achieved by not making it
available to the backend right away for reuse, but holding it a little while.
Historically, what has usually been the target of such attacks was objects,
where vtable pointers or other function pointers could constitute a valuable
targeti to replace. Those are usually on the smaller side. There is barely any
advantage in putting the quarantine several megabytes of RGB data or the like.
Now for the patch.
This patch introduces a new way the Quarantine behaves in Scudo. First of all,
the size of the Quarantine will be defined in KB instead of MB, then we
introduce a new option: the size up to which (lower than or equal to) a chunk
will be quarantined. This way, we only quarantine smaller chunks, and the size
of the quarantine remains manageable. It also prevents someone from triggering
a recycle by allocating something huge. We default to 512 bytes on 32-bit and
2048 bytes on 64-bit platforms.
In details, the patches includes the following:
- introduce `QuarantineSizeKb`, but honor `QuarantineSizeMb` if set to fall
back to the old behavior (meaning no threshold in that case);
`QuarantineSizeMb` is described as deprecated in the options descriptios;
documentation update will follow;
- introduce `QuarantineChunksUpToSize`, the new threshold value;
- update the `quarantine.cpp` test, and other tests using `QuarantineSizeMb`;
- remove `AllocatorOptions::copyTo`, it wasn't used;
- slightly change the logic around `quarantineOrDeallocateChunk` to accomodate
for the new logic; rename a couple of variables there as well;
Rewriting the tests, I found a somewhat annoying bug where non-default aligned
chunks would account for more than needed when placed in the quarantine due to
`<< MinAlignment` instead of `<< MinAlignmentLog`. This is fixed and tested for
now.
Reviewers: alekseyshl, kcc
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35694
llvm-svn: 308884
Summary:
This is a pure refactoring change. It just moves code that is
related to filesystem operations from sanitizer_common.{cc,h} to
sanitizer_file.{cc,h}. This makes it cleaner to disable the
filesystem-related code for a new port that doesn't want it.
Submitted on behalf of Roland McGrath.
Reviewers: kcc, eugenis, alekseyshl
Reviewed By: alekseyshl
Subscribers: vitalybuka, llvm-commits, kubamracek, mgorny, phosek
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35591
llvm-svn: 308819
Summary:
Included is one test for passing structs by value and one test for passing C++
objects by value.
Submitted on behalf of Matt Morehouse.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34827
llvm-svn: 308677
Summary: This will allow sanitizer_procmaps on mac to expose section information.
Reviewers: kubamracek, alekseyshl, kcc
Subscribers: llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D35422
llvm-svn: 308644
This is a pure refactoring change. It just moves code that is
related to filesystem operations from sanitizer_common.{cc,h} to
sanitizer_file.{cc,h}. This makes it cleaner to disable the
filesystem-related code for a new port that doesn't want it.
Commiting for mcgrathr.
Reviewers: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35591
llvm-svn: 308640
Summary:
Reuse Linux, FreeBSD and Apple code - no NetBSD specific changes.
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, vitalybuka, filcab, kcc
Reviewed By: filcab
Subscribers: emaste, kubamracek, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35628
llvm-svn: 308616
Summary:
Reuse Linux and FreeBSD - no NetBSD specific changes.
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, filcab, kcc, vitalybuka
Reviewed By: filcab
Subscribers: llvm-commits, emaste, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35629
llvm-svn: 308615
Summary:
Reuse Linux and FreeBSD code - no NetBSD specific changes.
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, vitalybuka, filcab
Reviewed By: filcab
Subscribers: emaste, kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35632
llvm-svn: 308614
Summary:
Thread id will be added to VRerort. Having thread here is useful.
This is also common place for logging for all sanitizers, so I can use this in
common test.
Reviewers: kcc, alekseyshl
Subscribers: kubamracek, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D35655
llvm-svn: 308578
This is a pure refactoring change. It simply moves all the code and
macros related to defining the ASan interceptor versions of memcpy,
memmove, and memset into a separate file. This makes it cleaner to
disable all the other interceptor code while still using these three,
for a port that defines these but not the other common interceptors.
Reviewers: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35590
llvm-svn: 308575
Summary:
Calling exit() from an atexit handler is undefined behavior.
On Linux, it's unavoidable, since we cannot intercept exit (_exit isn't called
if a user program uses return instead of exit()), and I haven't
seen it cause issues regardless.
However, on Darwin, I have a fairly complex internal test that hangs roughly
once in every 300 runs after leak reporting finishes, which is resolved with
this patch, and is presumably due to the undefined behavior (since the Die() is
the only thing that happens after the end of leak reporting).
In addition, this is the way TSan works as well, where an atexit handler+Die()
is used on Linux, and an _exit() interceptor is used on Darwin. I'm not sure if it's
intentionally structured that way in TSan, since TSan sets up the atexit handler and the
_exit() interceptor on both platforms, but I have observed that on Darwin, only the
_exit() interceptor is used, and on Linux the atexit handler is used.
There is some additional related discussion here: https://reviews.llvm.org/D35085
Reviewers: alekseyshl, kubamracek
Subscribers: eugenis, vsk, llvm-commits
Differential Revision: https://reviews.llvm.org/D35513
llvm-svn: 308353
Summary:
ASan/MSan/LSan allocators set errno on allocation failures according to
malloc/calloc/etc. expected behavior.
MSan allocator was refactored a bit to make its structure more similar
with other allocators.
Also switch Scudo allocator to the internal errno definitions.
TSan allocator changes will follow.
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D35275
llvm-svn: 308344
These tests assume allocator_may_return_null=false
If allocator_may_return_null=true, gtest would not be able to switch it.
Tests needs to be re-implemented as lit tests.
llvm-svn: 308254
Summary:
__DATA segments on Darwin contain a large number of separate sections,
most of which cannot actually contain pointers, and contain const values or
objc metadata. Only scanning sections which can contain pointers greatly improves
performance.
On a medium-sized (~4000 files) internal project, I saw a speedup of about 50%
in standalone LSan's execution time (50% improvement in the time spent running
LSan, not the total program time).
Reviewers: kcc, kubamracek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35432
llvm-svn: 308231
Summary:
Without them expressions like this may have different values.
(SANITIZER_INTERCEPT_MEMRCHR && SANITIZER_INTERCEPT_PREADV)
Reviewers: alekseyshl
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D35512
llvm-svn: 308228
Summary:
Introduce SI_NETBSD for NetBSD.
Add NetBSD support for appropriate `SANITIZER_INTERCEPT_*`.
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, dim, kcc, alekseyshl, filcab, eugenis, vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35468
llvm-svn: 308217
Summary:
Add defines for new NetBSD: SANITIZER_NETBSD,
it will be used across the codebase for sanitizers.
NetBSD is a POSIX-like platform, add it to SANITIZER_POSIX.
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, dim, alekseyshl, filcab, eugenis, vitalybuka
Reviewed By: kcc
Subscribers: kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35467
llvm-svn: 308216
Summary: This will allow sanitizer_procmaps on mac to expose section information.
Reviewers: kubamracek, alekseyshl, kcc
Subscribers: llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D35422
llvm-svn: 308210
Summary:
Set proper errno code on alloction failures and change some
implementations to satisfy their man-specified requirements:
LSan: valloc and memalign
ASan: pvalloc, memalign and posix_memalign
Changing both allocators in one patch since LSan depends on ASan allocator in some configurations.
Reviewers: vitalybuka
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D35440
llvm-svn: 308064
Set proper errno code on alloction failures and change valloc and
memalign implementations to satisfy their man-specified requirements.
llvm-svn: 308063
Summary:
Set proper errno code on alloction failure and change pvalloc and
posix_memalign implementation to satisfy their man-specified
requirements.
Reviewers: cryptoad
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35429
llvm-svn: 308053
This change implements 2 optimizations of sync clocks that reduce memory consumption:
Use previously unused first level block space to store clock elements.
Currently a clock for 100 threads consumes 3 512-byte blocks:
2 64-bit second level blocks to store clock elements
+1 32-bit first level block to store indices to second level blocks
Only 8 bytes of the first level block are actually used.
With this change such clock consumes only 2 blocks.
Share similar clocks differing only by a single clock entry for the current thread.
When a thread does several release operations on fresh sync objects without intervening
acquire operations in between (e.g. initialization of several fields in ctor),
the resulting clocks differ only by a single entry for the current thread.
This change reuses a single clock for such release operations. The current thread time
(which is different for different clocks) is stored in dirty entries.
We are experiencing issues with a large program that eats all 64M clock blocks
(32GB of non-flushable memory) and crashes with dense allocator overflow.
Max number of threads in the program is ~170 which is currently quite unfortunate
(consume 4 blocks per clock). Currently it crashes after consuming 60+ GB of memory.
The first optimization brings clock block consumption down to ~40M and
allows the program to work. The second optimization further reduces block consumption
to "modest" 16M blocks (~8GB of RAM) and reduces overall RAM consumption to ~30GB.
Measurements on another real world C++ RPC benchmark show RSS reduction
from 3.491G to 3.186G and a modest speedup of ~5%.
Go parallel client/server HTTP benchmark:
https://github.com/golang/benchmarks/blob/master/http/http.go
shows RSS reduction from 320MB to 240MB and a few percent speedup.
Reviewed in https://reviews.llvm.org/D35323
llvm-svn: 308018
Summary:
libsanitizer doesn't build against latest glibc anymore, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81066 for details.
One of the changes is that stack_t changed from typedef struct sigaltstack { ... } stack_t; to typedef struct { ... } stack_t; for conformance reasons.
And the other change is that the glibc internal __need_res_state macro is now ignored, so when doing
```
#define __need_res_state
#include <resolv.h>
```
the effect is now the same as just
```
#include <resolv.h>
```
and thus one doesn't get just the
```
struct __res_state { ... };
```
definition, but newly also the
```
extern struct __res_state *__res_state(void) __attribute__ ((__const__));
```
prototype. So __res_state is no longer a type, but a function.
Reviewers: kcc, ygribov
Reviewed By: kcc
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D35246
llvm-svn: 307969
Summary:
Secondary backed allocations do not require a cache. While it's not necessary
an issue when each thread has its cache, it becomes one with a shared pool of
caches (Android), as a Secondary backed allocation or deallocation holds a
cache that could be useful to another thread doing a Primary backed allocation.
We introduce an additional PRNG and its mutex (to avoid contention with the
Fallback one for Primary allocations) that will provide the `Salt` needed for
Secondary backed allocations.
I changed some of the code in a way that feels more readable to me (eg: using
some values directly rather than going through ternary assigned variables,
using directly `true`/`false` rather than `FromPrimary`). I will let reviewers
decide if it actually is.
An additional change is to mark `CheckForCallocOverflow` as `UNLIKELY`.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35358
llvm-svn: 307958
Summary:
We were missing many feature flags that newer gcc supports and we had our own set of feature flags that gcc didnt' support that were overlapping. Clang's implementation assumes gcc's features list so a mismatch here is problematic.
I've also matched the cpu type/subtype lists with gcc and removed all the cpus that gcc doesn't support. I've also removed the fallback autodetection logic that was taken from Host.cpp. It was the main reason we had extra feature flags relative to gcc. I don't think gcc does this in libgcc.
Once this support is in place we can consider implementing __builtin_cpu_is in clang. This could also be needed for function dispatching that Erich Keane is working on.
Reviewers: echristo, asbirlea, RKSimon, erichkeane, zvi
Reviewed By: asbirlea
Subscribers: dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D35214
llvm-svn: 307878
On iOS/AArch64, the address space is very limited and has a dynamic maximum address based on the configuration of the device. We're already using a dynamic shadow, and we find a large-enough "gap" in the VM where we place the shadow memory. In some cases and some device configuration, we might not be able to find a large-enough gap: E.g. if the main executable is linked against a large number of libraries that are not part of the system, these libraries can fragment the address space, and this happens before ASan starts initializing.
This patch has a solution, where we have a "backup plan" when we cannot find a large-enough gap: We will restrict the address space (via MmapFixedNoAccess) to a limit, for which the shadow limit will fit.
Differential Revision: https://reviews.llvm.org/D35098
llvm-svn: 307865
Add Fuchsia support to some builtings and avoid building builtins
that are not and will never be used on Fuchsia.
Differential Revision: https://reviews.llvm.org/D34075
llvm-svn: 307832
Summary:
This follows the addition of `GetRandom` with D34412. We remove our
`/dev/urandom` code and use the new function. Additionally, change the PRNG for
a slightly faster version. One of the issues with the old code is that we have
64 full bits of randomness per "next", using only 8 of those for the Salt and
discarding the rest. So we add a cached u64 in the PRNG that can serve up to
8 u8 before having to call the "next" function again.
During some integration work, I also realized that some very early processes
(like `init`) do not benefit from `/dev/urandom` yet. So if there is no
`getrandom` syscall as well, we have to fallback to some sort of initialization
of the PRNG.
Now a few words on why XoRoShiRo and not something else. I have played a while
with various PRNGs on 32 & 64 bit platforms. Some results are below. LCG 32 & 64
are usually faster but produce respectively 15 & 31 bits of entropy, meaning
that to get a full 64-bit, you would need to call them several times. The simple
XorShift is fast, produces 32 bits but is mediocre with regard to PRNG test
suites, PCG is slower overall, and XoRoShiRo is faster than XorShift128+ and
produces full 64 bits.
%%%
root@tulip-chiphd:/data # ./randtest.arm
[+] starting xs32...
[?] xs32 duration: 22431833053ns
[+] starting lcg32...
[?] lcg32 duration: 14941402090ns
[+] starting pcg32...
[?] pcg32 duration: 44941973771ns
[+] starting xs128p...
[?] xs128p duration: 48889786981ns
[+] starting lcg64...
[?] lcg64 duration: 33831042391ns
[+] starting xos128p...
[?] xos128p duration: 44850878605ns
root@tulip-chiphd:/data # ./randtest.aarch64
[+] starting xs32...
[?] xs32 duration: 22425151678ns
[+] starting lcg32...
[?] lcg32 duration: 14954255257ns
[+] starting pcg32...
[?] pcg32 duration: 37346265726ns
[+] starting xs128p...
[?] xs128p duration: 22523807219ns
[+] starting lcg64...
[?] lcg64 duration: 26141304679ns
[+] starting xos128p...
[?] xos128p duration: 14937033215ns
%%%
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: aemerson, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D35221
llvm-svn: 307798
1. Add SyncClock::ResetImpl which removes code
duplication between ctor and Reset.
2. Move SyncClock::Resize to SyncClock methods,
currently it's defined between ThreadClock methods.
llvm-svn: 307785
Don't create sync object if it does not exist yet. For example, an atomic
pointer is initialized to nullptr and then periodically acquire-loaded.
llvm-svn: 307778
The test should have been added in 289682
"tsan: allow Java VM iterate over allocated objects"
but I forgot to avn add.
Author: Alexander Smundak (asmundak)
Reviewed in https://reviews.llvm.org/D27720
llvm-svn: 307776
r307338 enabled new optimization reducing number of operation in tested functions.
There is no any performance regression detectable with TsanRtlTest DISABLED_BENCH.Mop* tests.
llvm-svn: 307739
Cleaner than using a while loop to copy the string character by character.
Reviewers: alekseyshl, glider
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35136
llvm-svn: 307696
Summary:
This function is only called once and is fairly simple. Inline to
keep API simple.
Reviewers: alekseyshl, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35270
llvm-svn: 307695
Summary:
This is the first in a series of patches to refactor sanitizer_procmaps
to allow MachO section information to be exposed on darwin.
In addition, grouping all segment information in a single struct is
cleaner than passing it through a large set of output parameters, and
avoids the need for annotations of NULL parameters for unneeded
information.
The filename string is optional and must be managed and supplied by the
calling function. This is to allow the MemoryMappedSegment struct to be
stored on the stack without causing overly large stack sizes.
Reviewers: alekseyshl, kubamracek, glider
Subscribers: emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D35135
llvm-svn: 307688
Printing stacktrace from ASAN crashes with a segfault in DEDUP mode when
symbolication is missing.
Differential Revision: https://reviews.llvm.org/D34914
llvm-svn: 307577
This patch ports the assembly file implementing TSan's setjmp support to AArch64 on Darwin.
Differential Revision: https://reviews.llvm.org/D35143
llvm-svn: 307541
Revert "Copy arguments passed by value into explicit allocas for ASan."
Revert "[asan] Add end-to-end tests for overflows of byval arguments."
Build failure on lldb-x86_64-ubuntu-14.04-buildserver.
Test failure on clang-cmake-aarch64-42vma and sanitizer-x86_64-linux-android.
llvm-svn: 307345
This improves find_darwin_sdk_dir to cache the results of executing xcodebuild to find the SDK. Should significantly reduce the CMake re-configure time.
Differential Revision: https://reviews.llvm.org/D34736
llvm-svn: 307344
Included is one test for passing structs by value and one test for passing C++
objects by value.
Patch by Matt Morehouse.
Differential revision: https://reviews.llvm.org/D34827
llvm-svn: 307343
Adds a CMake option DARWIN_PREFER_PUBLIC_SDK, off by default. When on, this prefers to use the public SDK, even when an internal one is present. With this, it's easy to emulate a build that the public buildbots are doing.
Differential Revision: https://reviews.llvm.org/D35071
llvm-svn: 307330
We currently hardcode the maximum VM address on iOS/AArch64, which is not really correct and this value changes between device configurations. Let's use TASK_VM_INFO to retrieve the maximum VM address dynamically.
Differential Revision: https://reviews.llvm.org/D35032
llvm-svn: 307307
The logic in GetMaxVirtualAddress is already pretty complex, and I want to get rid of the hardcoded value for iOS/AArch64, which would need adding more Darwin-specific code, so let's split the implementation into sanitizer_linux.cc and sanitizer_mac.cc files. NFC.
Differential Revision: https://reviews.llvm.org/D35031
llvm-svn: 307281
On Darwin, sigprocmask changes the signal mask for the entire process. This has some unwanted consequences, because e.g. internal_start_thread wants to disable signals only in the current thread (to make the new thread inherit the signal mask), which is currently broken on Darwin. This patch switches to pthread_sigmask.
Differential Revision: https://reviews.llvm.org/D35016
llvm-svn: 307212
Summary:
An attempt to reland D34786 (which caused bot failres on Mac), now with
properly intercepted operators new() and delete().
LSan allocator used to always return nullptr on too big allocation requests
(the definition of "too big" depends on platform and bitness), now it
follows policy configured by allocator_may_return_null flag
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34845
llvm-svn: 306845
This fixes an issue with the emission of lifetime markers for struct-returning Obj-C msgSend calls. When the result of a struct-returning call is ignored, the temporary storage is only marked with lifetime markers in one of the two branches of the nil-receiver-check. The check is, however, not required when the result is unused. If we still need to emit the check (due to consumer arguments), let's not emit the memset to zero out the result if it's unused. This fixes a use-after-scope false positive with AddressSanitizer.
Differential Revision: https://reviews.llvm.org/D34834
llvm-svn: 306838
Summary:
In `sanitizer_allocator_primary32.h`:
- rounding up in `MapWithCallback` is not needed as `MmapOrDie` does it. Note
that the 64-bit counterpart doesn't round up, this keeps the behavior
consistent;
- since `IsAligned` exists, use it in `AllocateRegion`;
- in `PopulateFreeList`:
- checking `b->Count` to be greater than 0 when `b->Count() == max_count` is
redundant when done more than once. Just check that `max_count` is greater
than 0 out of the loop; the compiler (at least on ARM) didn't optimize it;
- mark the batch creation failure as `UNLIKELY`;
In `sanitizer_allocator_primary64.h`:
- in `MapWithCallback`, mark the failure condition as `UNLIKELY`;
In `sanitizer_posix.h`:
- mark a bunch of Mmap related failure conditions as `UNLIKELY`;
- in `MmapAlignedOrDieOnFatalError`, we have `IsAligned`, so use it; rearrange
the conditions as one test was redudant;
- in `MmapFixedImpl`, 30 chars was not large enough to hold the message and a
full 64-bit address (or at least a 48-bit usermode address), increase to 40.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: aemerson, kubamracek, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D34840
llvm-svn: 306834
Summary:
Due to changes in semantics, CheckForCallocOverflow makes much more sense
now.
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34799
llvm-svn: 306747
Users can specify the path a raw profile is written to by passing
-fprofile-instr-generate=<path>, but this functionality broke on Darwin
after __llvm_profile_filename was made weak [1], resulting in profiles
being written to "default.profraw" even when <path> is specified.
The situation is that instrumented programs provide a weak definition of
__llvm_profile_filename, which conflicts with a weak redefinition
provided by the profiling runtime.
The linker appears to pick the 'winning' definition arbitrarily: on
Darwin, it usually prefers the larger definition, which is probably why
the instrprof-override-filename.c test has been passing.
The fix is to move the runtime's definition into a separate object file
within the archive. This means that the linker won't "see" the runtime's
definition unless the user program has not provided one. I couldn't
think of a great way to test this other than to mimic the Darwin
failure: use -fprofile-instr-generate=<some-small-path>.
Testing: check-{clang,profile}, modified instrprof-override-filename.c.
[1] [Profile] deprecate __llvm_profile_override_default_filename
https://reviews.llvm.org/D22613https://reviews.llvm.org/D22614
Differential Revision: https://reviews.llvm.org/D34797
llvm-svn: 306710
Do this by removing SANITIZER_INTERCEPT_WCSLEN and intercept wcslen
everywhere. Before this change, we were already intercepting wcslen on
Windows, but the interceptor was in asan, not sanitizer_common. After
this change, we stopped intercepting wcslen on Windows, which broke
asan_dll_thunk.c, which attempts to thunk to __asan_wcslen in the ASan
runtime.
llvm-svn: 306706
Summary:
We were not following the `man` documented behaviors for invalid arguments to
`memalign` and associated functions. Using `CHECK` for those was a bit extreme,
so we relax the behavior to return null pointers as expected when this happens.
Adapt the associated test.
I am using this change also to change a few more minor performance improvements:
- mark as `UNLIKELY` a bunch of unlikely conditions;
- the current `CHECK` in `__sanitizer::RoundUpTo` is redundant for us in *all*
calls. So I am introducing our own version without said `CHECK`.
- change our combined allocator `GetActuallyAllocatedSize`. We already know if
the pointer is from the Primary or Secondary, so the `PointerIsMine` check is
redundant as well, and costly for the 32-bit Primary. So we get the size by
directly using the available Primary functions.
Finally, change a `int` to `uptr` to avoid a warning/error when compiling on
Android.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34782
llvm-svn: 306698
Summary:
LSan allocator used to always return nullptr on too big allocation requests
(the definition of "too big" depends on platform and bitness), now it
follows policy configured by allocator_may_return_null flag.
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34786
llvm-svn: 306624
Summary:
Operator new interceptors behavior is now controlled by their nothrow
property as well as by allocator_may_return_null flag value:
- allocator_may_return_null=* + new() - die on allocation error
- allocator_may_return_null=0 + new(nothrow) - die on allocation error
- allocator_may_return_null=1 + new(nothrow) - return null
Ideally new() should throw std::bad_alloc exception, but that is not
trivial to achieve, hence TODO.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34731
llvm-svn: 306604
Summary:
This change introduces two files that show exaples of the
always/never instrument files that can be provided to clang. We don't
add these as defaults yet in clang, which we can do later on (in a
separate change).
We also add a test that makes sure that these apply in the compiler-rt
project tests, and that changes in clang don't break the expectations in
compiler-rt.
Reviewers: pelikan, kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34669
llvm-svn: 306502
Summary: Cleaner than computing the intersection for each possible sanitizer
Reviewers: compnerd, beanz
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34693
llvm-svn: 306453
Summary: This allows check-all to be used when only a subset of the sanitizers are built.
Reviewers: beanz, compnerd, rnk, pcc
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34644
llvm-svn: 306450
Introduces a 'owner' struct to include the overridable write
method and the write context in C.
This allows easy introdution of new member API to help reduce
profile merge time in the follow up patch.
llvm-svn: 306432
Summary: This allows check-all to be used when only a subset of the sanitizers are built.
Reviewers: beanz, compnerd
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34644
llvm-svn: 306415
Summary:
Make SizeClassAllocator32 return nullptr when it encounters OOM, which
allows the entire sanitizer's allocator to follow allocator_may_return_null=1
policy, even for small allocations (LargeMmapAllocator is already fixed
by D34243).
Will add a test for OOM in primary allocator later, when
SizeClassAllocator64 can gracefully handle OOM too.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34433
llvm-svn: 305972
Summary:
AFAICT compiler-rt doesn't have a function that would return 'good' random
bytes to seed a PRNG. Currently, the `SizeClassAllocator64` uses addresses
returned by `mmap` to seed its PRNG, which is not ideal, and
`SizeClassAllocator32` doesn't benefit from the entropy offered by its 64-bit
counterpart address space, so right now it has nothing. This function aims at
solving this, allowing to implement good 32-bit chunk randomization. Scudo also
has a function that does this for Cookie purposes, which would go away in a
later CL once this lands.
This function will try the `getrandom` syscall if available, and fallback to
`/dev/urandom` if not.
Unfortunately, I do not have a way to implement and test a Mac and Windows
version, so those are unimplemented as of now. Note that `kRandomShuffleChunks`
is only used on Linux for now.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: zturner, rnk, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34412
llvm-svn: 305922
Change some reinterpret_casts to c-style casts due to template instantiation
restrictions and build breakage due to missing paranthesises.
llvm-svn: 305899
Summary:
On Android we still need to reset preinstalled handlers and allow use handlers later.
This reverts commit r304039.
Reviewers: eugenis
Subscribers: kubamracek, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D34434
llvm-svn: 305871
Summary:
Move cached allocator_may_return_null flag to sanitizer_allocator.cc and
provide API to consolidate and unify the behavior of all specific allocators.
Make all sanitizers using CombinedAllocator to follow
AllocatorReturnNullOrDieOnOOM() rules to behave the same way when OOM
happens.
When OOM happens, turn allocator_out_of_memory flag on regardless of
allocator_may_return_null flag value (it used to not to be set when
allocator_may_return_null == true).
release_to_os_interval_ms and rss_limit_exceeded will likely be moved to
sanitizer_allocator.cc too (later).
Reviewers: eugenis
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34310
llvm-svn: 305858
Summary:
ASan shadow memory on s390 is larger than other configurations, let's
disable this test for now (will revisit it later).
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34414
llvm-svn: 305822
Summary:
This is required for standalone LSan to work with libdispatch worker threads,
and is a slimmed down version of the functionality provided for ASan
in asan_mac.cc.
Re-commit of r305695 with use_stacks=0 to get around a racy lingering pointer.
Reviewers: alekseyshl, kubamracek, glider, kcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D34247
llvm-svn: 305732
Summary:
This is required for standalone LSan to work with libdispatch worker threads,
and is a slimmed down version of the functionality provided for ASan
in asan_mac.cc.
Reviewers: alekseyshl, kubamracek, glider, kcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D34247
llvm-svn: 305695
This test makes sure we can handle both arg0 and arg1 handling in the
same binary, and making sure that the XRay runtime calls the correct
trampoline when handlers for both of these cases are installed.
llvm-svn: 305660
Summary:
Since r298413, the NEW behavior of the CMake policy CMP0056 is followed.
However, it is only effective after the call to cmake_minimum_required.
This causes CMAKE_EXE_LINKER_FLAGS etc. to be unused when CMake tries to
check compilers for languages specified in the 'project' declaration.
Set cmake_minimum_required(VERSION) at the top of the file and ahead of
the project declaration.
Reviewers: beanz
Subscribers: mgorny, srhines, llvm-commits
Differential Revision: https://reviews.llvm.org/D34282
llvm-svn: 305593
Summary:
CombinedAllocator::Allocate cleared parameter is not used anywhere and
seem to be obsolete.
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34289
llvm-svn: 305590
The first instruction of the new ucrtbase!strnlen implementation loads a
global, presumably to dispatch between SSE and non-SSE optimized strnlen
implementations.
Fixes PR32895 and probably
https://github.com/google/sanitizers/issues/818
llvm-svn: 305581
Summary:
Point of failure is different after D34243, hence the change of the
message.
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34292
llvm-svn: 305580
Summary:
Context: https://github.com/google/sanitizers/issues/740.
Making secondary allocator to respect allocator_may_return_null=1 flag
and return nullptr when "out of memory" happens.
More changes in primary allocator and operator new will follow.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34243
llvm-svn: 305569
Summary:
This allows us to do more interesting things with the data available to
C++ methods, to log the `this` pointer.
Depends on D34050.
Reviewers: pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34051
llvm-svn: 305545
The dynamic type check needs to inspect vtables, but could crash if it
encounters a vtable pointer to inaccessible memory. In the first attempt
to fix the issue (r304437), we performed a memory accessibility check on
the wrong range of memory. This should *really* fix the problem.
Patch by Max Moroz!
Differential Revision: https://reviews.llvm.org/D34215
llvm-svn: 305489
Summary:
After r303941 it was not possible to setup ASAN_OPTIONS to have the same
behavior for pre r303941 and post r303941 builds.
Pre r303941 Asan does not accept handle_sigbus=2.
Post r303941 Asan does not accept allow_user_segv_handler.
This fix ignores allow_user_segv_handler=1, but for allow_user_segv_handler=0
it will upgrade flags like handle_sigbus=1 to handle_sigbus=2. So user can set
ASAN_OPTIONS=allow_user_segv_handler=0 and have same behavior on old and new
clang builds (except range from r303941 to this revision).
In future users which need to prevent third party handlers should switch to
handle_sigbus=2 and remove allow_user_segv_handler as soon as suport of older
builds is not needed.
Related bugs:
https://github.com/google/oss-fuzz/issues/675https://bugs.chromium.org/p/chromium/issues/detail?id=731130
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34227
llvm-svn: 305433
Summary:
This broke thread_local_quarantine_pthread_join.cc on some architectures, due
to the overhead of the stashed regions. Reverting while figuring out the best
way to deal with it.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34213
llvm-svn: 305404
Summary:
The reasoning behind this change is explained in D33454, which unfortunately
broke the Windows version (due to the platform not supporting partial unmapping
of a memory region).
This new approach changes `MmapAlignedOrDie` to allow for the specification of
a `padding_chunk`. If non-null, and the initial allocation is aligned, this
padding chunk will hold the address of the extra memory (of `alignment` bytes).
This allows `AllocateRegion` to get 2 regions if the memory is aligned
properly, and thus help reduce fragmentation (and saves on unmapping
operations). As with the initial D33454, we use a stash in the 32-bit Primary
to hold those extra regions and return them on the fast-path.
The Windows version of `MmapAlignedOrDie` will always return a 0
`padding_chunk` if one was requested.
Reviewers: alekseyshl, dvyukov, kcc
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34152
llvm-svn: 305391
Summary:
Move the OOM decision based on RSS limits out of generic allocator to
ASan allocator, where it makes more sense at the moment.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34180
llvm-svn: 305342
This patch addresses PR 33206. There might be a situation when dynamic ASan runtime initializes later
than shared library which has malloc in static constructor (rtld doesn't provide an order of shared libs initialization).
In this case ASan hasn't yet initialized interceptors, but already intercepts malloc.
If malloc is too big to be handled by static local pool, ASan will die with error:
Sanitizer CHECK failed: lib/asan/asan_malloc_linux.cc:40 ((allocated_for_dlsym)) < ((kDlsymAllocPoolSize)) (1036, 1024)
Patch by Denis Khalikov.
Differential Revision: https://reviews.llvm.org/D33784
llvm-svn: 305058
This reverts commit r304941. Vitaly Buka writes:
"Actually it depends on return value.
Test is for char* version of function. It will probably fail for int
version."
llvm-svn: 304943
On Darwin, strerror_r returns an int, not a char*. I don't think this
test really depends on what strerror_r returns, so I've used something
else in place of the result of the call to strerror_r.
llvm-svn: 304941
GNU version of strerror_r returns a result pointer that doesn't match the input
buffer. The result pointer is in fact a pointer to some internal storage.
TSAN was recording a write to this location, which was incorrect.
Fixed https://github.com/google/sanitizers/issues/696
llvm-svn: 304858
Summary:
As mentioned in test/msan/fork.cc, if test output is redirected to a file
(as opposed to being piped directly to FileCheck), we may lose some "done"s due to
a kernel bug: https://lkml.org/lkml/2014/2/17/324, so let's pipe the
output of the test.
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33915
llvm-svn: 304744
r304285 - [sanitizer] Avoid possible deadlock in child process after fork
r304297 - [sanitizer] Trying to fix MAC buildbots after r304285
These changes create deadlock when Tcl calls pthread_create from a
pthread_atfork child handler. More info in the original review at
https://reviews.llvm.org/D33325
llvm-svn: 304735
Summary:
halt_on_error-torture.cc intermittently fails on ppc64be, let's try to
collect more info on failures.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D33912
llvm-svn: 304731
Revert "Mark sancov test as unsupported on Darwin"
Revert "[LSan] Detect dynamic loader by its base address."
This reverts commit r304633.
This reverts commit r304673.
This reverts commit r304632.
Those commit have broken LOTS of ARM/AArch64 bots for two days.
llvm-svn: 304699
atos is apparently not able to resolve symbol addresses properly on
i386-darwin reliably any more. This is causing bot flakiness:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/6841
There have not been any SDK changes on the bot as of late.
/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/llvm/projects/compiler-rt/test/asan/TestCases/Darwin/atos-symbolizer.cc:20:12: error: expected string not found in input
// CHECK: #1 0x{{.*}} in main {{.*}}atos-symbolizer.cc:[[@LINE-4]]
^
<stdin>:35:27: note: scanning from here
#0 0x112f56 in wrap_free (/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/clang-build/lib/clang/5.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib:i386+0x56f56)
^
<stdin>:35:27: note: with expression "@LINE-4" equal to "16"
#0 0x112f56 in wrap_free (/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/clang-build/lib/clang/5.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib:i386+0x56f56)
^
<stdin>:36:168: note: possible intended match here
#1 0xb6f20 in main (/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/clang-build/tools/clang/runtime/compiler-rt-bins/test/asan/I386DarwinConfig/TestCases/Darwin/Output/atos-symbolizer.cc.tmp:i386+0x1f20)
llvm-svn: 304674
This test has been failing on all Darwin bots since it was introduced:
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_check/32111
fatal error: error in backend: Global variable '__sancov_gen_' has an invalid section specifier '__DATA,__sancov_counters': mach-o section specifier requires a section whose length is between 1 and 16 characters.
Target: x86_64-apple-darwin15.6.0
llvm-svn: 304673
Summary:
Very recently, FreeBSD 12 has been updated to use 64-bit inode numbers:
<https://svnweb.freebsd.org/changeset/base/318737>. This entails many
user-visible changes, but for the sanitizers the modifications are
limited in scope:
* The `stat` and `lstat` syscalls were removed, and should be replaced
with calls to `fstatat`.
* The `getdents` syscall was removed, and should be replaced with calls
to `getdirentries`.
* The layout of `struct dirent` was changed to accomodate 64-bit inode
numbers, and a new `d_off` field was added.
* The system header <sys/_types.h> now contains a macro `__INO64` to
determine whether the system uses 64-bit inode numbers.
I tested these changes on both FreeBSD 12.0-CURRENT (after r318959,
which adds the `__INO64` macro), and FreeBSD 11.0-STABLE (which still
uses 32-bit inode numbers).
Reviewers: emaste, kcc, vitalybuka, kubamracek
Reviewed By: vitalybuka
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33600
llvm-svn: 304658
Summary:
Whenever possible (Linux + glibc 2.16+), detect dynamic loader module by
its base address, not by the module name matching. The current name
matching approach fails on some configurations.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D33859
llvm-svn: 304633
There is can be a situation when vptr is not initializing
by constructor of the object, and has a junk data which should
be properly checked, because c++ standard says:
"if default constructor is not specified
16 (7.3) no initialization is performed."
Patch by Denis Khalikov!
Differential Revision: https://reviews.llvm.org/D33712
llvm-svn: 304437
This patch addresses https://github.com/google/sanitizers/issues/774. When we
fork a multi-threaded process it's possible to deadlock if some thread acquired
StackDepot or allocator internal lock just before fork. In this case the lock
will never be released in child process causing deadlock on following memory alloc/dealloc
routine. While calling alloc/dealloc routines after multi-threaded fork is not allowed,
most of modern allocators (Glibc, tcmalloc, jemalloc) are actually fork safe. Let's do the same
for sanitizers except TSan that has complex locking rules.
Differential Revision: https://reviews.llvm.org/D33325
llvm-svn: 304285
Summary:
D33521 addressed a memory ordering issue in BlockingMutex, which seems
to be the cause of a flakiness of a few ASan tests on PowerPC.
Reviewers: eugenis
Subscribers: kubamracek, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D33611
llvm-svn: 304045
The test was meant for Darwin anyway, so I'm not even sure it's supposed
to run on Linux. If it was, then we need time to investigate, but since
the test is new, there's no point in reverting the whole patch because
of it.
llvm-svn: 304010
Summary:
Currently we are not enforcing the success of `pthread_once`, and
`pthread_setspecific`. Errors could lead to harder to debug issues later in
the thread's life. This adds checks for a 0 return value for both.
If `pthread_setspecific` fails in the teardown path, opt for an immediate
teardown as opposed to a fatal failure.
Reviewers: alekseyshl, kcc
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33555
llvm-svn: 303998
Summary:
D33521 addressed a memory ordering issue in BlockingMutex, which seems
to be the cause of a flakiness of a few ASan tests on PowerPC.
Reviewers: eugenis
Subscribers: kubamracek, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D33569
llvm-svn: 303995
Summary:
allow_user_segv_handler had confusing name did not allow to control behavior for
signals separately.
Reviewers: eugenis, alekseyshl, kcc
Subscribers: llvm-commits, dberris, kubamracek
Differential Revision: https://reviews.llvm.org/D33371
llvm-svn: 303941
Summary:
This required for any users who call exit() after creating
thread-specific data, as tls destructors are only called when
pthread_exit() or pthread_cancel() are used. This should also
match tls behavior on linux.
Getting the base address of the tls section is straightforward,
as it's stored as a section offset in %gs. The size is a bit trickier
to work out, as there doesn't appear to be any official documentation
or source code referring to it. The size used in this patch was determined
by taking the difference between the base address and the address of the
subsequent memory region returned by vm_region_recurse_64, which was
1024 * sizeof(uptr) on all threads except the main thread, where it was
larger. Since the section must be the same size on all of the threads,
1024 * sizeof(uptr) seemed to be a reasonable size to use, barring
a more programtic way to get the size.
1024 seems like a reasonable number, given that PTHREAD_KEYS_MAX
is 512 on darwin, so pthread keys will fit inside the region while
leaving space for other tls data. A larger size would overflow the
memory region returned by vm_region_recurse_64, and a smaller size
wouldn't leave room for all the pthread keys. In addition, the
stress test added here passes, which means that we are scanning at
least the full set of possible pthread keys, and probably
the full tls section.
Reviewers: alekseyshl, kubamracek
Subscribers: krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D33215
llvm-svn: 303887
The existing implementation ran CHECKs to assert that the thread state
was stored inside the tls. However, the mac implementation of tsan doesn't
store the thread state in tls, so these checks fail once darwin tls support
is added to the sanitizers. Only run these checks on platforms where
the thread state is expected to be contained in the tls.
llvm-svn: 303886
Summary:
Apparently Windows's `UnmapOrDie` doesn't support partial unmapping. Which
makes the new region allocation technique not Windows compliant.
Reviewers: alekseyshl, dvyukov
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33554
llvm-svn: 303883
Summary:
Currently, AllocateRegion has a tendency to fragment memory: it allocates
`2*kRegionSize`, and if the memory is aligned, will unmap `kRegionSize` bytes,
thus creating a hole, which can't itself be reused for another region. This
is exacerbated by the fact that if 2 regions get allocated one after another
without any `mmap` in between, the second will be aligned due to mappings
generally being contiguous.
An idea, suggested by @alekseyshl, to prevent such a behavior is to have a
stash of regions: if the `2*kRegionSize` allocation is properly aligned, split
it in two, and stash the second part to be returned next time a region is
requested.
At this point, I thought about a couple of ways to implement this:
- either an `IntrusiveList` of regions candidates, storing `next` at the
begining of the region;
- a small array of regions candidates existing in the Primary.
While the second option is more constrained in terms of size, it offers several
advantages:
- security wise, a pointer in a region candidate could be overflowed into, and
abused when popping an element;
- we do not dirty the first page of the region by storing something in it;
- unless several threads request regions simultaneously from different size
classes, the stash rarely goes above 1 entry.
I am not certain about the Windows impact of this change, as `sanitizer_win.cc`
has its own version of MmapAlignedOrDie, maybe someone could chime in on this.
MmapAlignedOrDie is effectively unused after this change and could be removed
at a later point. I didn't notice any sizeable performance gain, even though we
are saving a few `mmap`/`munmap` syscalls.
Reviewers: alekseyshl, kcc, dvyukov
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33454
llvm-svn: 303879
Summary:
Dmitry, seeking your expertise. I believe, the proper way to implement
Lock/Unlock here would be to use acquire/release semantics. Am I missing
something?
Reviewers: dvyukov
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33521
llvm-svn: 303869
Summary:
In FreeBSD we needed to add generic implementations for `__bswapdi2` and
`__bswapsi2`, since gcc 6.x for mips is emitting calls to these. See:
https://reviews.freebsd.org/D10838 and https://reviews.freebsd.org/rS318601
The actual mips code generated for these generic C versions is pretty
OK, as can be seen in the (FreeBSD) review.
I checked over gcc sources, and it seems that it can emit these calls on
more architectures, so maybe it's best to simply always add them to the
compiler-rt builtins library.
Reviewers: howard.hinnant, compnerd, petarj, emaste
Reviewed By: compnerd, emaste
Subscribers: mgorny, llvm-commits, arichardson
Differential Revision: https://reviews.llvm.org/D33516
llvm-svn: 303866
This test case occassionally fails when run on powerpc64 be.
asan/TestCases/Posix/halt_on_error-torture.cc
The failure causes false problem reports to be sent to developers whose
code had nothing to do with the failures. Reactivate it when the real
problem is fixed.
This could also be related to the same problems as with the tests
ThreadedOneSizeMallocStressTest, ThreadedMallocStressTest, ManyThreadsTest,
and several others that do not run reliably on powerpc.
llvm-svn: 303864
Summary:
This flags is not covered by tests on Windows and looks like it's implemented
incorrectly. Switching its default breaks some tests.
Taking into account that related handle_segv flag is not supported on Windows
it's safer to remove it until we commit to support it.
Reviewers: eugenis, zturner, rnk
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D33471
llvm-svn: 303728
Summary: We are going to make it tri-state and remove allow_user_segv_handler.
Reviewers: eugenis, alekseys, kcc
Subscribers: kubamracek, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D33159
llvm-svn: 303464
Summary:
The LINKEDIT section is very large and is read-only. Scanning this
section caused LSan on darwin to be very slow. When only writable sections
are scanned for global pointers, performance improved by a factor of about 25x.
Reviewers: alekseyshl, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33322
llvm-svn: 303422
Summary:
After discussing the current defaults with a couple of parties, the consensus
is that they are too high. 1Mb of quarantine has about a 4Mb impact on PSS, so
memory usage goes up quickly.
This is obviously configurable, but the default value should be more
"approachable", so both the global size and the thread local size are 1/4 of
what they used to be.
Reviewers: alekseyshl, kcc
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33321
llvm-svn: 303380
The sanitizer library unit tests for libc can get a different definition
of 'struct stat' to what the sanitizer library is built with for certain
targets.
For MIPS the size element of 'struct stat' is after a macro guarded
explicit padding element.
This patch resolves any possible inconsistency by adding the same
_FILE_OFFSET_BITS=64 and _LARGE_SOURCE with the same
conditions as the sanitizer library to the build flags for the unit tests.
This resolves a recurring build failure on the MIPS buildbots due to
'struct stat' defintion differences.
Reviewers: slthakur
Differential Revision: https://reviews.llvm.org/D33131
llvm-svn: 303350
It's used in asan_test.cc also on Windows, and my build was failing
with:
C:/src/llvm/projects/compiler-rt/lib/asan/tests/asan_test.cc:549:28: error: unknown type name 'jmp_buf'
NOINLINE void LongJmpFunc1(jmp_buf buf) {
^
C:/src/llvm/projects/compiler-rt/lib/asan/tests/asan_test.cc:569:10: error: unknown type name 'jmp_buf'
static jmp_buf buf;
^
I couldn't find what changed to make this not work anymore, but this should fix
it.
llvm-svn: 303273
Summary:
This required for any users who call exit() after creating
thread-specific data, as tls destructors are only called when
pthread_exit() or pthread_cancel() are used. This should also
match tls behavior on linux.
Getting the base address of the tls section is straightforward,
as it's stored as a section offset in %gs. The size is a bit trickier
to work out, as there doesn't appear to be any official documentation
or source code referring to it. The size used in this patch was determined
by taking the difference between the base address and the address of the
subsequent memory region returned by vm_region_recurse_64, which was
1024 * sizeof(uptr) on all threads except the main thread, where it was
larger. Since the section must be the same size on all of the threads,
1024 * sizeof(uptr) seemed to be a reasonable size to use, barring
a more programtic way to get the size.
1024 seems like a reasonable number, given that PTHREAD_KEYS_MAX
is 512 on darwin, so pthread keys will fit inside the region while
leaving space for other tls data. A larger size would overflow the
memory region returned by vm_region_recurse_64, and a smaller size
wouldn't leave room for all the pthread keys. In addition, the
stress test added here passes, which means that we are scanning at
least the full set of possible pthread keys, and probably
the full tls section.
Reviewers: alekseyshl, kubamracek
Subscribers: krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D33215
llvm-svn: 303262
This inclusion is needed to fix the ARM build. The int_lib.h include is
slightly ugly, but allows us to use the `AEABI_RTABI` macro to decorate
the CC for the functions.
llvm-svn: 303190
These actually may change calling conventions. We cannot simply provide
function aliases as the aliased function may have a different calling
convention. Provide a forwarding function instead to permit the
compiler to synthesize the calling convention adjustment thunk.
Remove the `ARM_EABI_FNALIAS` macro as that is not safe to use.
Resolves PR33030!
llvm-svn: 303188
Summary: Use __linux__ to check for Linux and bring back the check for __GNU__.
Reviewers: echristo, krytarowski, compnerd, rengolin
Reviewed By: krytarowski
Subscribers: phosek, llvm-commits, srhines
Differential Revision: https://reviews.llvm.org/D33219
llvm-svn: 303131
Some build targets (e.g. i686) have aliased names (e.g. i386). We would
get multiple definitions previously and have the linker arbitrarily
select a definition on those aliased targets. Make this more
deterministic by checking those aliases.
llvm-svn: 303103
Add a lit substitution (I chose %gmlt) so that only stack trace tests
get debug info.
We need a lit substition so that this expands to -gline-tables-only
-gcodeview on Windows. I think in the future we should reconsider the
need for -gcodeview from the GCC driver, but for now, this is necessary.
llvm-svn: 303083
Summary:
With rL279771, SizeClassAllocator64 was changed to accept only one template
instead of 5, for the following reasons: "First, this will make the mangled
names shorter. Second, this will make adding more parameters simpler". This
patch mirrors that work for SizeClassAllocator32.
This is in preparation for introducing the randomization of chunks in the
32-bit SizeClassAllocator in a later patch.
Reviewers: kcc, alekseyshl, dvyukov
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33141
llvm-svn: 303071
This fixes tests that use debug info to check ubsan stack traces. One
was XFAILd on Windows and the other was actively failing for weeks.
llvm-svn: 302924
These tests don't fail consistently in all cases, but they
fail most of the time on the buildbots. Mark as UNSUPPORTED for now to
avoid buildbots failing due to XPASS.
llvm-svn: 302920
Our theory is that reserving large amounts of shadow memory isn't
reliable on Win7 and earlier NT kernels. This affects the
clang-x64-ninja-win7 buildbot, which uses Windows 7.
llvm-svn: 302917
Summary:
Sanitizer procmaps uses dyld apis to iterate over the list of images
in the process. This is much more performan than manually recursing
over all of the memory regions in the process, however, dyld does
not report itself in the list of images. In order to prevent reporting
leaks from dyld globals and to symbolize dyld functions in stack traces,
this patch special-cases dyld and ensures that it is added to the
list of modules.
This is accomplished by recursing through the memory map of the process
until a dyld Mach header is found. While this recursion is expensive,
it is run before the full set of images has been loaded in the process,
so only a few calls are required. The result is cached so that it never
needs to be searched for when the full process memory map exists, as this
would be incredibly slow, on the order of minutes for leak sanitizer with
only 25 or so libraries loaded.
Reviewers: alekseyshl, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32968
llvm-svn: 302899
thread_get_register_pointer_values handles the redzone computation
automatically, but is marked as an unavailable API function. This
patch replicates its logic accounting for the stack redzone on
x86_64.
Should fix flakiness in the use_stack_threaded test for lsan on darwin.
llvm-svn: 302898
This is a follow-up to r302787, which broke MemorySanitizer.ICmpRelational.
MSan is now reporting a false positive on the following test case:
TestForNotPoisoned((poisoned(-1, 0x80000000U) >= poisoned(-1, 0U)))
, which is sort of anticipated, because we're approximating the comparison
with an OR of the arguments' shadow values.
llvm-svn: 302887
We only have an implementation in x86_64 that works for the
patching/unpatching and runtime support (trampolines).
Follow-up to D30630.
llvm-svn: 302873
Summary:
This change implements support for the custom event logging sleds and
intrinsics at runtime. For now it only supports handling the sleds in
x86_64, with the implementations for other architectures stubbed out to
do nothing.
NOTE: Work in progress, uploaded for exposition/exploration purposes.
Depends on D27503, D30018, and D33032.
Reviewers: echristo, javed.absar, timshen
Subscribers: mehdi_amini, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D30630
llvm-svn: 302857
Summary:
The reasoning behind this change is twofold:
- the current combined allocator (sanitizer_allocator_combined.h) implements
features that are not relevant for Scudo, making some code redundant, and
some restrictions not pertinent (alignments for example). This forced us to
do some weird things between the frontend and our secondary to make things
work;
- we have enough information to be able to know if a chunk will be serviced by
the Primary or Secondary, allowing us to avoid extraneous calls to functions
such as `PointerIsMine` or `CanAllocate`.
As a result, the new scudo-specific combined allocator is very straightforward,
and allows us to remove some now unnecessary code both in the frontend and the
secondary. Unused functions have been left in as unimplemented for now.
It turns out to also be a sizeable performance gain (3% faster in some Android
memory_replay benchmarks, doing some more on other platforms).
Reviewers: alekseyshl, kcc, dvyukov
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33007
llvm-svn: 302830
This breaks several tests because we don't always have
access to __cxa_guard functions
This reverts commit 45eb470c3e9e8f6993a204e247c33d4092237efe.
llvm-svn: 302693
Summary:
This bug is caused by the incorrect handling of return-value registers.
According to OpenPOWER 64-Bit ELF V2 ABI 2.2.5, up to 2 general-purpose
registers are going to be used for return values, and up to 8 floating
point registers or vector registers are going to be used for return
values.
Reviewers: dberris, echristo
Subscribers: nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D33027
llvm-svn: 302691
Summary:
The test fails on PPC, because the address of a function may vary
depending on whether the "taker" shares the same ToC (roughly, in the
same "module") as the function.
Therefore the addresses of the functions taken in func-id-utils.cc may be
different from the addresses taken in xray runtime.
Change the test to be permissive on address comparison.
Reviewers: dberris, echristo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33026
llvm-svn: 302686
Disable building enable_execute_stack.c for targets that do not have
support for mprotect().
Differential Revision: https://reviews.llvm.org/D33018
llvm-svn: 302680
Summary:
Sanitizer procmaps uses dyld apis to iterate over the list of images
in the process. This is much more performan than manually recursing
over all of the memory regions in the process, however, dyld does
not report itself in the list of images. In order to prevent reporting
leaks from dyld globals and to symbolize dyld functions in stack traces,
this patch special-cases dyld and ensures that it is added to the
list of modules.
This is accomplished by recursing through the memory map of the process
until a dyld Mach header is found. While this recursion is expensive,
it is run before the full set of images has been loaded in the process,
so only a few calls are required. The result is cached so that it never
needs to be searched for when the full process memory map exists, as this
would be incredibly slow, on the order of minutes for leak sanitizer with
only 25 or so libraries loaded.
Reviewers: alekseyshl, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32968
llvm-svn: 302673
Some configuration (for instance default docker ubuntu images) uses
a default empty and invalid /etc/fstab configuration file. It makes
any call to getmntent return NULL and it leads to failures on
Msan-aarch64{-with-call}-Test/MemorySanitizer.getmntent{_r}.
This patch fixes it by creating a temporary file with some valid
entries (although not valid for the system) to use along with
setmntent/getmntent.
llvm-svn: 302639
By default glibc writes its diagnostics directly to tty so the `2>&1 |`
redirection in the test doesn't catch the *** stack smashing detected ***
message, which in turn breaks printing the lit's progress bar. By defining
the LIBC_FATAL_STDERR_ environment variable we force glibc to direct
diagnostic messages to stderr.
Differential Revision: https://reviews.llvm.org/D32599
llvm-svn: 302628
This commit made ubsan use the fast unwinder. On SystemZ this requires
test cases to be compiled with -mbackchain. That was already done for
asan, but not ubsan. Add the flag for ubsan as well.
llvm-svn: 302562
Summary:
This change optimizes several aspects of the checksum used for chunk headers.
First, there is no point in checking the weak symbol `computeHardwareCRC32`
everytime, it will either be there or not when we start, so check it once
during initialization and set the checksum type accordingly.
Then, the loading of `HashAlgorithm` for SSE versions (and ARM equivalent) was
not optimized out, while not necessary. So I reshuffled that part of the code,
which duplicates a tiny bit of code, but ends up in a much cleaner assembly
(and faster as we avoid an extraneous load and some calls).
The following code is the checksum at the end of `scudoMalloc` for x86_64 with
full SSE 4.2, before:
```
mov rax, 0FFFFFFFFFFFFFFh
shl r10, 38h
mov edi, dword ptr cs:_ZN7__scudoL6CookieE ; __scudo::Cookie
and r14, rax
lea rsi, [r13-10h]
movzx eax, cs:_ZN7__scudoL13HashAlgorithmE ; __scudo::HashAlgorithm
or r14, r10
mov rbx, r14
xor bx, bx
call _ZN7__scudo20computeHardwareCRC32Ejm ; __scudo::computeHardwareCRC32(uint,ulong)
mov rsi, rbx
mov edi, eax
call _ZN7__scudo20computeHardwareCRC32Ejm ; __scudo::computeHardwareCRC32(uint,ulong)
mov r14w, ax
mov rax, r13
mov [r13-10h], r14
```
After:
```
mov rax, cs:_ZN7__scudoL6CookieE ; __scudo::Cookie
lea rcx, [rbx-10h]
mov rdx, 0FFFFFFFFFFFFFFh
and r14, rdx
shl r9, 38h
or r14, r9
crc32 eax, rcx
mov rdx, r14
xor dx, dx
mov eax, eax
crc32 eax, rdx
mov r14w, ax
mov rax, rbx
mov [rbx-10h], r14
```
Reviewers: dvyukov, alekseyshl, kcc
Reviewed By: alekseyshl
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D32971
llvm-svn: 302538
Summary: This should significantly improve darwin lsan performance in cases where root regions are not used.
Reviewers: alekseyshl, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32966
llvm-svn: 302530
Summary:
This change adds Android support to the allocator (but doesn't yet enable it in
the cmake config), and should be the last fragment of the rewritten change
D31947.
Android has more memory constraints than other platforms, so the idea of a
unique context per thread would not have worked. The alternative chosen is to
allocate a set of contexts based on the number of cores on the machine, and
share those contexts within the threads. Contexts can be dynamically reassigned
to threads to prevent contention, based on a scheme suggested by @dvyuokv in
the initial review.
Additionally, given that Android doesn't support ELF TLS (only emutls for now),
we use the TSan TLS slot to make things faster: Scudo is mutually exclusive
with other sanitizers so this shouldn't cause any problem.
An additional change made here, is replacing `thread_local` by `THREADLOCAL`
and using the initial-exec thread model in the non-Android version to prevent
extraneous weak definition and checks on the relevant variables.
Reviewers: kcc, dvyukov, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D32649
llvm-svn: 302300
Follow-up on D32846 to simplify testing and not rely on FileCheck to
test boundary conditions, and instead do all the testing in code
instead.
llvm-svn: 302212
Summary:
This change allows us to provide users and implementers of XRay handlers
a means of converting XRay function id's to addresses. This, in
combination with the facilities provided in D32695, allows users to find
out:
- How many function id's there are defined in the current binary.
- Get the address of the function associated with this function id.
- Patch only specific functions according to their requirements.
While we don't directly provide symbolization support in XRay, having
the function's address lets users determine this information easily
either during runtime, or offline with tools like 'addr2line'.
Reviewers: dblaikie, echristo, pelikan
Subscribers: kpw, llvm-commits
Differential Revision: https://reviews.llvm.org/D32846
llvm-svn: 302210
Summary:
glibc on Linux calls __longjmp_chk instead of longjmp (or _longjmp) when
_FORTIFY_SOURCE is defined. Ensure that an ASAN-instrumented program
intercepts this function when a system library calls it, otherwise the
stack might remain poisoned and result in CHECK failures and false
positives.
Fixes https://github.com/google/sanitizers/issues/721
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D32408
llvm-svn: 302152
Match the builtins that GCC provides for IEEE754 quad precision
on MIPS64. Also, enable building them with clang as PR20098 is resolved.
Disable tests for xf and xc modes as MIPS doesn't support that mode in
hardware or software.
Reviewers: slthakur
Differential Revision: https://reviews.llvm.org/D32794
llvm-svn: 302147
Summary:
This change allows us to patch/unpatch specific functions using the
function ID. This is useful in cases where implementations might want to
do coverage-style, or more fine-grained control of which functions to
patch or un-patch at runtime.
Depends on D32693.
Reviewers: dblaikie, echristo, kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32695
llvm-svn: 302112
This patch allows the Swift compiler to emit calls to `__tsan_external_write` before starting any modifying access, which will cause TSan to detect races on arrays, dictionaries and other classes defined in non-instrumented modules. Races on collections from the Swift standard library and user-defined structs and a frequent cause of subtle bugs and it's important that TSan detects those on top of existing LLVM IR instrumentation, which already detects races in direct memory accesses.
Differential Revision: https://reviews.llvm.org/D31630
llvm-svn: 302050
This patch marks a few ASan tests as unsupported on iOS. These are mostly tests that use files or paths that are invalid/inaccessible on iOS or the simulator. We currently don't have a good way of propagating/copying secondary files that individual tests need. The same problem exists on Android, so I'm just marking the tests as UNSUPPORTED now.
Differential Revision: https://reviews.llvm.org/D32632
llvm-svn: 301966
The fast reset for large memory regions is not working
only on windows. So enable it for Go/linux/darwin/freebsd.
See https://github.com/golang/go/issues/20139
for background and motivation.
Based on idea by Josh Bleecher Snyder.
llvm-svn: 301927
Summary:
TSan's Android `__get_tls()` and `TLS_SLOT_TSAN` can be used by other sanitizers as well (see D32649), this change moves them to sanitizer_common.
I picked sanitizer_linux.h as their new home.
In the process, add the 32-bit versions for ARM, i386 & MIPS.
Can the address of `__get_tls()[TLS_SLOT_TSAN]` change in between the calls?
I am not sure if there is a need to repeat the construct as opposed to using a variable. So I left things as they were.
Testing on my side was restricted to a successful cross-compilation.
Reviewers: dvyukov, kubamracek
Reviewed By: dvyukov
Subscribers: aemerson, rengolin, srhines, dberris, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D32705
llvm-svn: 301926
This makes it possible to get stacktrace info when print_stacktrace=1 on
Darwin (where the slow unwinder is not currently supported [1]). This
should not regress any other platforms.
[1] The thread about r300295 has a relatively recent discusion about
this. We should be able to enable the existing slow unwind functionality
for Darwin, but this needs more testing.
Differential Revision: https://reviews.llvm.org/D32517
llvm-svn: 301839
These test cases occassionally fail when run on powerpc64le:
ignore_lib1.cc
ignore_lib5.cc
TestCases/Posix/current_allocated_bytes.cc
rtl/TsanRtlTest/Posix.ThreadLocalAccesses
TestCases/Posix/coverage-fork-direct.cc
The failures cause false problem reports to be sent to developers whose
code had nothing to do with the failures. Reactivate them when the real
problems are fixed.
This could also be related to the same problems as with the tests
ThreadedOneSizeMallocStressTest, ThreadedMallocStressTest, ManyThreadsTest,
and several others that do not run reliably on powerpc.
llvm-svn: 301798
For a linker init mutex with lazy flag setup
(no __tsan_mutex_create call), it is possible that
no lock/unlock happened before the destroy call.
Then when destroy runs we still don't know that
it is a linker init mutex and will emulate a memory write.
This in turn can lead to false positives as the mutex
is in fact linker initialized.
Support linker init flag in destroy annotation to resolve this.
llvm-svn: 301795
Summary:
In this patch we document the requirements for implementations that want
to install handlers for the dynamically-controlled XRay "framework".
This clarifies what the expectations are for implementations that
want to install their handlers using this API (similar to how the FDR
logging implementation does so). It also gives users some guarantees on
semantics for the APIs.
If all goes well, users can decide to use the XRay APIs to control the
tracing/logging at the application level, without having to depend on
implementation details of the installed logging implementation. This
lets users choose the implementation that comes with compiler-rt, or
potentially multiple other implementations that use the same APIs.
We also add one convenience function (__xray_remove_log_impl()) for
explicitly removing the currently installed log implementation.
Reviewers: kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32579
llvm-svn: 301784
To make the TSan external API work with Swift and other use cases, we need to track "tags" for individual memory accesses. Since there is no space to store this information in shadow cells, let's use the thread traces for that. This patch stores the tag as an extra frame in the stack traces (by calling FuncEntry and FuncExit with the address of a registered tag), this extra frame is then stripped before printing the backtrace to stderr.
Differential Revision: https://reviews.llvm.org/D32382
llvm-svn: 301777
Tests that run on the iOS simulator require the dlopen'd dylibs are codesigned. This patch adds the "iossim_compile.py" wrapper that codesigns any produces dylib.
Differential Revision: https://reviews.llvm.org/D32561
llvm-svn: 301617
Summary:
This change introduces scudo_tls.h & scudo_tls_linux.cpp, where we move the
thread local variables used by the allocator, namely the cache, quarantine
cache & prng. `ScudoThreadContext` will hold those. This patch doesn't
introduce any new platform support yet, this will be the object of a later
patch. This also changes the PRNG so that the structure can be POD.
Reviewers: kcc, dvyukov, alekseyshl
Reviewed By: dvyukov, alekseyshl
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D32440
llvm-svn: 301584
This patch adds "%env" as a way to express that the environment variable should be set on the target device/simulator. This fixes some test failures when testing on iOS/Simulator.
Differential Revision: https://reviews.llvm.org/D32556
llvm-svn: 301462
This patch adds a basic support for running the ASan lit test suite against an iOS Simulator. This is done by generating more lit.site.cfg configurations into subdirectories such as IOSSimI386Config and IOSSimX86_64Config. These test suites are not added into "check-all" or into "check-asan", they have to be run manually.
Differential Revision: https://reviews.llvm.org/D31477
llvm-svn: 301443
Summary:
Generalize already defined LSan suppression for the leak on
tls_get_addr, some envs do not have the entire call stack symbolized,
so we have to be less specific.
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32545
llvm-svn: 301434
Cover the sanitizer tests with COMPILER_RT_BUILD_SANITIZERS
conditional, and add COMPILER_RT_BUILD_XRAY conditional to the xray
tests. This makes it possible to do a pure-builtins build with tests
enabled.
Differential Revision: https://reviews.llvm.org/D32489
llvm-svn: 301387
Summary:
LLVM JIT needs to be able to use emulated TLS on all platforms, and this provides a reference one can compile to enable emutls for Linux/Mac/Windows.
Reviewers: chh, howard.hinnant
Reviewed By: chh
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D30787
llvm-svn: 301350
Summary:
Generalize already defined LSan suppression for the leak on
pthread_exit, some envs do not have the entire call stack symbolized,
so we have to be less specific.
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32497
llvm-svn: 301335
This broke the self-host build on Windows (PR32777).
Original commit message:
> [builtins] Implement emulated TLS on Windows.
>
> Summary:
> LLVM JIT needs to be able to use emulated TLS on all platforms, and this provides a reference one can compile to enable emutls for Linux/Mac/Windows.
>
> Reviewers: chh, howard.hinnant
>
> Reviewed By: chh
>
> Subscribers: mgorny, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D30787
llvm-svn: 301274
Summary:
`SizeClassForTransferBatch` is expensive and is called for every `CreateBatch`
and `DestroyBatch`. Caching it means `kNumClasses` calls in `InitCache`
instead. This should be a performance gain if more than `kNumClasses / 2`
batches are created and destroyed during the lifetime of the local cache.
I have chosen to fully remove the function and putting the code in `InitCache`,
which is a debatable choice.
In single threaded benchmarks leveraging primary backed allocations, this turns
out to be a sizeable gain in performances (greater than 5%). In multithreaded
benchmarks leveraging everything, it is less significant but still an
improvement (about 1%).
Reviewers: kcc, dvyukov, alekseyshl
Reviewed By: dvyukov
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D32365
llvm-svn: 301184
Summary:
LLVM JIT needs to be able to use emulated TLS on all platforms, and this provides a reference one can compile to enable emutls for Linux/Mac/Windows.
Reviewers: chh, howard.hinnant
Reviewed By: chh
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D30787
llvm-svn: 301089
These were added in r301016, but they're failing, because
-fsanitize=cfi seemingly causes -flto=thin to emit raw bitcode objects,
rather than the mach-o-wrapped bitcode we emit with -flto=thin alone.
That causes all tests to fail with ld64 errors.
Filed PR32741.
llvm-svn: 301065
Summary:
strchr interceptor does not need to call strlen if strict_string_checks is not
enabled. Unnecessary strlen calls affect python parser performance.
Reviewers: eugenis, kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D32264
llvm-svn: 301027
Summary:
In the current state of things, the deallocation path puts a chunk in the
Quarantine whether it's enabled or not (size of 0). When the Quarantine is
disabled, this results in the header being loaded (and checked) twice, and
stored (and checksummed) once, in `deallocate` and `Recycle`.
This change introduces a `quarantineOrDeallocateChunk` function that has a
fast path to deallocation if the Quarantine is disabled. Even though this is
not the preferred configuration security-wise, this change saves a sizeable
amount of processing for that particular situation (which could be adopted by
low memory devices). Additionally this simplifies a bit `deallocate` and
`reallocate`.
Reviewers: dvyukov, kcc, alekseyshl
Reviewed By: dvyukov
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32310
llvm-svn: 301015
We need to make sure that the "external" API isn't dup'ing all data races into a single one (because the stack might look the same) and suppressing all external races. This works now, so just adding a test for that.
Differential Revision: https://reviews.llvm.org/D31734
llvm-svn: 301011
On Darwin, the setting ignore_noninstrumented_modules is used to suppress false positives in code that users don't have control of. The recently added "external" API (which can be used to detect races on objects provided by system libraries, but the race is actually user's fault) ignores this flag and it can report issues in non-instrumented modules. This patch fixes that.
Differential Revision: https://reviews.llvm.org/D31553
llvm-svn: 301000
This patch make sure we don't report deadlocks and other bug types when we're inside an interceptor that was called from a noninstrumented module (when ignore_noninstrumented_modules=1 is set). Adding a testcase that shows that deadlock detection still works on Darwin (to make sure we're not silencing too many reports).
Differential Revision: https://reviews.llvm.org/D31449
llvm-svn: 300998
At least one of the ARM bots is still broken:
Command Output (stderr):
--
/home/buildslave/buildslave/clang-cmake-armv7-a15-full/llvm/projects/compiler-rt/test/asan/TestCases/Posix/strchr.c:31:12: error: expected string not found in input
// CHECK: strchr.c:[[@LINE-2]]
^
<stdin>:3:59: note: scanning from here
==16297==ERROR: AddressSanitizer: SEGV on unknown address 0xb5add000 (pc 0xb6dccaa4 bp 0xbe8c19c8 sp 0xbe8c1570 T0)
^
<stdin>:3:59: note: with expression "@LINE-2" equal to "29"
==16297==ERROR: AddressSanitizer: SEGV on unknown address 0xb5add000 (pc 0xb6dccaa4 bp 0xbe8c19c8 sp 0xbe8c1570 T0)
^
<stdin>:5:57: note: possible intended match here
#0 0xb6dccaa3 in strlen /build/glibc-f8FFOS/glibc-2.23/string/../sysdeps/arm/armv6t2/strlen.S:82
Try to fix by reverting r300889 and subsequent fixes:
Revert "[asan] Fix test by removing "The signal is caused" check."
Revert "[asan] Fix test on ppc64le-linux by checking "UNKNOWN memory access""
Revert "[asan] Match BUS and SIGV to fix test on Darwin"
Revert "[asan] Optimize strchr for strict_string_checks=false"
llvm-svn: 300955
Summary:
The textdomain function accepts a NULL parameter (and should then return the
current message domain). Add a check for this and include ASAN tests.
Link: https://github.com/google/sanitizers/issues/787
Reviewers: m.guseva, kcc
Reviewed By: kcc
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D32318
llvm-svn: 300924
Summary:
This already appears to be the case in all .cc test files,
it was probably left out of the .c test files accidentally. Make it a global
default, instead of manually adding it to each individual test.
This is needed to force leak detection for Darwin tests, where leak detection
is disabled by default.
Reviewers: m.ostapenko, kubamracek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32297
llvm-svn: 300890
Summary:
strchr interceptor does not need to call strlen if strict_string_checks is not
enabled. Unnecessary strlen calls affect python parser performance.
Reviewers: eugenis, kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D32264
llvm-svn: 300889
Summary:
GetActuallyAllocatedSize is actually expensive. In order to avoid calling this
function in the malloc/free fast path, we change the Scudo chunk header to
store the size of the chunk, if from the Primary, or the amount of unused
bytes if from the Secondary. This way, we only have to call the culprit
function for Secondary backed allocations (and still in realloc).
The performance gain on a singly threaded pure malloc/free benchmark exercising
the Primary allocator is above 5%.
Reviewers: alekseyshl, kcc, dvyukov
Reviewed By: dvyukov
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32299
llvm-svn: 300861
Summary:
This is part of D31947 that is being split into several smaller changes.
This one deals with all the minor changes, more specifically:
- Rename some variables and functions to make their purpose clearer;
- Reorder some code;
- Mark the hot termination incurring checks as `UNLIKELY`; if they happen, the
program will die anyway;
- Add a `getScudoChunk` method;
- Add an `eraseHeader` method to ScudoChunk that will clear a header with 0s;
- Add a parameter to `allocate` to know if the allocated chunk should be filled
with zeros. This allows `calloc` to not have to call
`GetActuallyAllocatedSize`; more changes to get rid of this function on the
hot paths will follow;
- reallocate was missing a check to verify that the pointer is properly
aligned on `MinAlignment`;
- The `Stats` in the secondary have to be protected by a mutex as the `Add`
and `Sub` methods are actually not atomic;
- The software CRC32 function was moved to the header to allow for inlining.
Reviewers: dvyukov, alekseyshl, kcc
Reviewed By: dvyukov
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32242
llvm-svn: 300846
Summary:
The thread order test fails sometimes my machine independently of standalone
build.
From testing both standalone and in-tree build, I see I configured it wrong.
The other hypothesis for an issue is that cold starts can interfere with whether
record unwriting happens. Once this happens more than once, we can naively
FileCheck on the wrong test output, which compounds the issue.
While "rm blah.* || true" will print to stderr if the glob can't expand, this is
mostly harmless and makes sure earlier failing tests don't sabotage us.
Example failure:
---
header:
version: 1
type: 1
constant-tsc: true
nonstop-tsc: true
cycle-frequency: 3800000000
records:
- { type: 0, func-id: 1, function: 'f1()', cpu: 9, thread: 21377, kind: function-enter, tsc: 2413745203147228 }
- { type: 0, func-id: 1, function: 'f1()', cpu: 9, thread: 21377, kind: function-exit, tsc: 2413745203304238 }
...
The CMAKE related change fixes the expectation that COMPILER_RT_STANDALONE_BUILD will be explicitly FALSE instead
of empty string when it is not "TRUE".
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32259
llvm-svn: 300822
Summary:
This is a follow-up to D32202.
While the previous change (D32202) did fix the stack alignment issue, we
were still at a weird state in terms of the CFI/CFA directives (as the
offsets were wrong). This change cleans up the SAVE/RESTORE macros for
the trampoline, accounting the stack pointer adjustments with less
instructions and with some clearer math. We note that the offsets will
be different on the exit trampolines, because we don't typically 'call'
into this trampoline and we only ever jump into them (i.e. treated as a
tail call that's patched in at runtime).
Reviewers: eugenis, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32214
llvm-svn: 300815
Summary:
In the general case, we only need to check for root regions inside
the memory map returned by procmaps. However, on Darwin,
we also need to check inside mmap'd regions, which aren't returned
in the list of modules we get from procmaps.
This patch refactors memory region scanning on darwin to reduce
code duplication with the kernel alloc once page scan.
Reviewers: kubamracek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32190
llvm-svn: 300760
Summary:
On PowerPC and ARM (possibly, need to verify), couple tests involving
pthread_exit fail due to leaks detected by LSan. pthread_exit tries
to perform unwinding that leads to dlopen'ing libgcc_s.so. dlopen
mallocs "libgcc_s.so" string which confuses LSan, it fails to
realize that this allocation happens in dynamic linker and should
be ignored.
Symbolized leak report is required to define a suppression for this
known problem.
Reviewers: eugenis
Subscribers: aemerson, rengolin, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D32194
Turn symbolization on for PPC and Thumb only to do not slow down other platforms.
llvm-svn: 300748
Summary:
Tests that generate output with compiler-rt and verify it with the llvm_xray
command (built from the llvm tree) are extremely convenient, but compiler-rt
can be built out of tree and llvm_xray is not built for every target.
This change intends to disable tests for out of tree builds, but does nothing
to detect whether llvm_xray can be found elsewhere on the path, is fresh enough,
or is part of a build target for the in tree build.
Tested:
Tested that this didn't break check-xray. Haven't reproduced bots or standalone
builds.
Reviewers: dberris, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32150
llvm-svn: 300716
Summary:
ProcessPlatformSpecificAllocations for linux leak sanitizer iterated over
memory chunks and ran two checks concurrently:
1) Ensured the pc was valid
2) Checked whether it was a linker allocation
All platforms will need the valid pc check, so it is moved out of the platform-
specific file. To prevent code and logic duplication, the linker allocation
check is moved as well, with the name of the linker supplied by the platform-specific
module. In cases where we don't need to check for linker allocations (ie Darwin),
this name will be a nullptr, and we'll only run the caller pc checks.
Reviewers: kubamracek, alekseyshl, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32130
llvm-svn: 300690
Summary:
Previously, we had been very undisciplined about CFI annotations with
the XRay trampolines. This leads to runtime crashes due to mis-alined
stack pointers that some function implementations may run into (i.e.
those using instructions that require properly aligned addresses coming
from the stack). This patch attempts to clean that up, as well as more
accurately use the correct amounts of space on the stack for stashing
and un-stashing registers.
Reviewers: eugenis, kcc
Subscribers: kpw, llvm-commits
Differential Revision: https://reviews.llvm.org/D32202
llvm-svn: 300660
Summary:
This option is disabled by our other test suites, and will cause
failures when unit tests abort instead of failing with an error code.
Will also prevent the test suite from being too slow.
Reviewers: kubamracek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32129
llvm-svn: 300593
Turned out that adding defined(_arm_) in sanitizer_stoptheworld_linux_libcdep.cc breaks android arm with some toolchains.
.../llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:36:11: fatal error:
'linux/user.h' file not found
# include <linux/user.h> // for pt_regs
^
1 error generated.
Context:
#if SANITIZER_ANDROID && defined(__arm__)
# include <linux/user.h> // for pt_regs
#else
This patch removes corresponding #if SANITIZER_ANDROID && defined(__arm__) and a bit rearranges adjacent сode.
Differential Revision: https://reviews.llvm.org/D32128
llvm-svn: 300531
A problem arises if a machine supports the rdtscp instruction, but the processor
frequency cannot be determined by the function getTSCFrequency(). In this case,
we want to use the emulated TSC instead. This patch implements that by adding a
call to getTSCFrequency() from probeRequiredCPUFeatures(), and the function only
returns true if both the processor supports rdtscp and the CPU frequency can be
determined.
This should fix PR32620.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32067
llvm-svn: 300525
Summary:
On Darwin, we need to track thread and tid as separate values.
This patch splits out the implementation of the suspended threads list
to be OS-specific.
Reviewers: glider, kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31474
llvm-svn: 300491
We seem to assume that OS-provided thread IDs are either uptr or int, neither of which is true on Darwin. This introduces a tid_t type, which holds a OS-provided thread ID (gettid on Linux, pthread_threadid_np on Darwin, pthread_self on FreeBSD).
Differential Revision: https://reviews.llvm.org/D31774
llvm-svn: 300473
Summary: This specifically addresses the Mach-O zero page, which we cannot read from.
Reviewers: kubamracek, samsonov, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32044
llvm-svn: 300456
When using ASan and UBSan together, the common sanitizer tool name is
set to "AddressSanitizer". That means that when a UBSan diagnostic is
printed out, it looks like this:
SUMMARY: AddressSanitizer: ...
This can confuse users. Fix it so that we always use the correct tool
name when printing out UBSan diagnostics.
Differential Revision: https://reviews.llvm.org/D32066
llvm-svn: 300358
Summary:
These checks appear linux-specific, disable them on darwin, at
least for now.
Reviewers: kubamracek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32013
llvm-svn: 300248
Summary:
These tests aren't supported on other platforms, move them
to their own directory.
Reviewers: kubamracek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32034
llvm-svn: 300247
Summary:
Lsan was using PTHREAD_CREATE_JOINABLE/PTHREAD_CREATE_DETACHED
as truthy values, which works on Linux, where the values are 0 and 1,
but this fails on OS X, where the values are 1 and 2.
Set PTHREAD_CREATE_DETACHED to the correct value for a given system.
Reviewers: kcc, glider, kubamracek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31883
llvm-svn: 300221
Summary:
Allocator::ClassIdToSize() is not free and calling it in every
Allocate/Deallocate has noticeable impact on perf.
Reapplying D31991 with the appropriate fixes.
Reviewers: cryptoad
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D32024
llvm-svn: 300216
Summary:
With D31555 commited, looks like basic LSan functionality
works on PPC64. Time to enable LSan there.
Reviewers: eugenis
Subscribers: nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D31995
llvm-svn: 300204
Summary:
The darwin interceptor for malloc_destroy_zone manually frees the
zone struct, but does not free the name component. Make sure to
free the name if it has been set.
Reviewers: kubamracek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31983
llvm-svn: 300195
Bind to ANY as some machines may have IPv6 support but without IPv6 on loopback
interface.
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31998
llvm-svn: 300150
Summary:
Allocator::ClassIdToSize() is not free and calling it in every
Allocate/Deallocate has noticeable impact on perf.
Reviewers: eugenis, kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D31991
llvm-svn: 300107
Summary:
This is used for the other architectures in print_address, but is
missing from i386 and arm.
Reviewers: m.ostapenko, spetrovic
Subscribers: aemerson, rengolin, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D31977
llvm-svn: 300065
I didn't pay enough attention to the patch I reverted, now I'm going to
hit it with a bigger hammer until we can understand what the problems
are.
llvm-svn: 300044
This reverts commit r299957. It broke the Thumb bots. We need to make
sure why and maybe stop it from being tested on Thumb environments. But
for now, let's get the bots green.
llvm-svn: 300042
Summary:
While there, make the threshold in ticks for the rewind computed only
once and not per function, unify the two versions we had and slightly
reformat bits according to coding standards.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31971
llvm-svn: 300028
Summary:
Not repeating screamy failure paths makes the 300+ line function a bit shorter.
There's no need to overload the variable name "Buffer" if it only works on the
thread local buffer. Fix some comments while there.
I plan to move the rewinding logic into a separate function too, but in this
diff it would be too much of a mess to comprehend. This is trivially NFC.
Reviewers: kpw, dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31930
llvm-svn: 300018
This patch applies a work-around to the XRay FDR tests when TSC emulation is
needed because the processor frequency cannot be determined.
This fixes PR32620 using the suggestion given by Dean in comment 1.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31967
llvm-svn: 300017
Summary:
Mimicks the existing tsan and asan implementations of
Darwin interception.
Reviewers: kubamracek, kcc, glider
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31889
llvm-svn: 299979
Summary:
The routines for thread destruction in the thread registry require
the lsan thread index, which is stored in pthread tls on OS X.
This means that we need to make sure that the lsan tls isn't destroyed
until after the thread registry tls. This change ensures that we
don't delete the lsan tls until we've finished destroying the thread
in the registry, ensuring that the destructor for the lsan tls runs
after the destructor for the thread registry tls.
This patch also adds a check to ensure that the thread ID is valid before
returning it in GetThreadID(), to ensure that the above behavior
is working correctly.
Reviewers: dvyukov, kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31884
llvm-svn: 299978
Previously in r297800, a work-around was created to use TSC emulation on x86_64 when RDTSCP was not available on the host. A similar change was needed in the file xray_fdr_logging.cc which this patch ports over to that file.
Eventually the code should be refactored as there will be 3 locations with the same code, but that can be done as a separate step. This patch is just to keep the test from failing on my machine due to an illegal instruction since RDTSCP is not available on my x86_64 linux VM.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31909
llvm-svn: 299922
Summary:
We can move this functionality into LLVM's tools instead, as it no
longer is strictly required for the compiler-rt testing infrastructure.
It also is blocking the successful bootstrapping of the clang compiler
due to a missing virtual destructor in one of the flag parsing library.
Since this binary isn't critical for the XRay runtime testing effort
anymore (yet), we remove it in the meantime with the hope of moving the
functionality in LLVM proper instead.
Reviewers: kpw, pelikan, rnk, seurer, eugenis
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31926
llvm-svn: 299916
Summary:
Set up the proper stack frame for the thread spawned in internal_clone,
the current code does not follow ABI (and causes SEGV trying to use this
malformed frame).
Reviewers: wschmidt
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D31555
llvm-svn: 299896
Avoid __attribute__((constructor)) in cpu_model.c.
Use more C99 _Complex emulation in divtc3.c. Joerg Sonnenberger added
this builtin just after the last round of C99 _Complex emulation landed
in r249514 (Oct 2015).
llvm-svn: 299784
Many things were broken:
- We stopped building most builtins on Windows in r261432 for reasons
that are not at all clear to me. This essentially reverts that patch.
- Fix %librt to expand to clang_rt.builtins-$arch.lib on Windows instead
of libclang_rt.builtins-$arch.a.
- Fix memory protection tests (trampoline, enable executable, clear
cache) on Windows. One issue was that the MSVC incremental linker
generates ILT thunks for functions with external linkage, so memcpying
the functions into the executable stack buffer wasn't working. You
can't memcpy an RIP-relative jump without fixing up the offset.
- Disable tests that rely on C99 complex library functions when using
the MSVC CRT, which isn't compatible with clang's C99 _Complex.
In theory, these could all be separate patches, but it would not green
the tests, so let's try for it all at once. Hopefully this fixes the
clang-x64-ninja-win7 bot.
llvm-svn: 299780
Summary:
During MIPS implementation work for FreeBSD, John Baldwin (jhb@FreeBSD.org)
found that gcc 6.x emits calls to __ffssi2() when compiling libc and some
userland programs in the base system.
Add it to compiler-rt's builtins, based off of the existing __ffsdi2()
implementation. Also update the CMake files and add a test case.
Reviewers: howard.hinnant, weimingz, rengolin, compnerd
Reviewed By: weimingz
Subscribers: dberris, mgorny, llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D31721
llvm-svn: 299675
Summary:
Recently, Clang enabled the check for virtual destructors
in the presence of virtual methods. That broke the bootstrap
build. Fixing it.
Reviewers: pcc
Reviewed By: pcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D31776
llvm-svn: 299672
r299658 fixed a case where InstCombine was replicating instructions instead of combining. Fixing this reduced the number of pushes and pops in the __tsan_read and __tsan_write functions.
Adjust the expectations to account for this after talking to Dmitry Vyukov.
llvm-svn: 299661
This patch addresses two issues:
* It turned out that suspended thread may have dtls->dtv_size == kDestroyedThread (-1)
and LSan wrongly assumes that DTV is available. This leads to SEGV when LSan tries to
iterate through DTV that is invalid.
* In some rare cases GetRegistersAndSP can fail with errno 3 (ESRCH). In this case LSan
assumes that the whole stack of a given thread is available. This is wrong because ESRCH
can indicate that suspended thread was destroyed and its stack was unmapped. This patch
properly handles ESRCH from GetRegistersAndSP in order to avoid invalid accesses to already
unpapped threads stack.
Differential Revision: https://reviews.llvm.org/D30818
llvm-svn: 299630
Summary:
"short" is defined as an xray flag, and buffer rewinding happens for both exits
and tail exits.
I've made the choice to seek backwards finding pairs of FunctionEntry, TailExit
record pairs and erasing them if the FunctionEntry occurred before exit from the
currently exiting function. This is a compromise so that we don't skip logging
tail calls if the function that they call into takes longer our duration.
This works by counting the consecutive function and function entry, tail exit
pairs that proceed the current point in the buffer. The buffer is rewound to
check whether these entry points happened recently enough to be erased.
It is still possible we will omit them if they call into a child function that
is not instrumented which calls a fast grandchild that is instrumented before
doing other processing.
Reviewers: pelikan, dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31345
llvm-svn: 299629
Summary: Need to save `lr` before bl to aeabi_div0
Reviewers: rengolin, compnerd
Reviewed By: compnerd
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31716
llvm-svn: 299628
There are two cases to consider:
We are using the internal shell. This will still fail because of
ulimit.
We are using an external shell. In this case the difference is that we
now also constrain FileCheck to use less than 4 MB of of stack, which
it should :-)
llvm-svn: 299586
This works with a regular shell since the kernel can keep track of a
deleted cwd. Since we just keep a path string, the following
subprocess invocations fail.
I think this would also fail on windows.
llvm-svn: 299471
The patch addresses https://github.com/google/sanitizers/issues/786. Currently AsanCheckDynamicRTPrereqs prevents
dynamic ASan runtime from running in some important environments e.g. cowbuilder and fakeroot that may also work with interposition.
Let's allow users to switch off the check given that they know what they do.
Differential Revision: https://reviews.llvm.org/D31420
llvm-svn: 299188
AddressSanitizer has an optional compile-time flag, -fsanitize-address-use-after-scope, which enables detection of use-after-scope bugs. We'd like to have this feature on by default, because it is already very well tested, it's used in several projects already (LLVM automatically enables it when using -DLLVM_USE_SANITIZER=Address), it's low overhead and there are no known issues or incompatibilities.
This patch enables use-after-scope by default via the Clang driver, where we set true as the default value for AsanUseAfterScope. This also causes the lifetime markers to be generated whenever fsanitize=address is used. This has some nice consequences, e.g. we now have line numbers for all local variables.
Differential Revision: https://reviews.llvm.org/D31479
llvm-svn: 299175
TSan reports a false positive when using xpc_connection_cancel. We're missing a happens-before edge from xpc_connection_cancel to the event handler on the same connection.
Differential Revision: https://reviews.llvm.org/D31475
llvm-svn: 299086
Summary:
This is already assumed by the test suite, and by
asan_flags.cc.
Reviewers: m.ostapenko, vitalybuka, kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31462
llvm-svn: 299082
I am working on improving our internal bot infrastructure. One thing
that is unique to the ps4 is that we want to run the posix tests, but
have to execute them on windows.
We currently have a local hack to use a shell on windows, but it is
pretty much impossible to get all all the tools to play nice with all
the heuristics for what is a path and what is a command line option.
This adds support LIT_USE_INTERNAL_SHELL and I will then try to fix
the tests that fail with it but adding the missing features.
llvm-svn: 299077
{M, T, E}San have fread and fwrite interceptors, let's move them to sanitizer_common to enable ASan checks as well.
Differential Revision: https://reviews.llvm.org/D31456
llvm-svn: 299061
Until llvm-xray starts running/supporting binaries that are not ELF64 we
only run the FDR tests on x86_64-linux. Previous changes caused the
tests to not actually run on x86_64.
Follow-up on D31454.
llvm-svn: 299050
When -fsanitize-address-use-after-scope is used, the instrumentation produces line numbers in stack frame descriptions. This patch make sure the ASan runtime supports this format (ParseFrameDescription needs to be able to parse "varname:line") and prepares lit tests to allow line numbers in ASan report output.
Differential Revision: https://reviews.llvm.org/D31484
llvm-svn: 299043
Summary:
This change allows us to do an end-to-end test of the FDR mode
implementation that uses the llvm-xray tooling to verify that what we
are both writing and reading the data in a consistent manner.
Reviewers: kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31454
llvm-svn: 299042
Summary:
Now that we have a platform-specific non-common lsan file, use
it to store non-common lsan data.
Reviewers: kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31472
llvm-svn: 299032
Summary:
We currently don't have any platform specific darwin
lsan modules, don't force failure if they don't exist.
Reviewers: kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31473
llvm-svn: 299031
Summary:
I know of two implementations that do this (ASan is not protecting against accessing the returned memory for now, just like malloc(0)):
SIE libc on the PS4
dlmalloc has a flag for this
This allows us to properly support this behaviour.
Reviewers: vsk, kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D31295
llvm-svn: 299016
The same test fails on clang-cmake-armv7-a15-full biuld bot
but passes the clang-cmake-thumbv7-a15-full.
For now, we mark it as UNSUPPORTED for armhf target.
Bug 32457 tracks it.
llvm-svn: 299005
It was XFAILed in r298974. However, the problem was not exposed on
the buildbot because hardfp flag was not passed during the test.
We can fix the CMAKE to pass the same flag as building the lib to the
RUN line to see if the problem is still there. For now, we remove the
XFAIL.
llvm-svn: 298997
Summary:
Currently the FDR log writer, upon flushing, dumps a sequence of buffers from
its freelist to disk. A reader can read the first buffer up to an EOB record,
but then it is unclear how far ahead to scan to find the next threads traces.
There are a few ways to handle this problem.
1. The reader has externalized knowledge of the buffer size.
2. The size of buffers is in the file header or otherwise encoded in the log.
3. Only write out the portion of the buffer with records. When released, the
buffers are marked with a size.
4. The reader looks for memory that matches a pattern and synchronizes on it.
2 and 3 seem the most flexible and 2 does not rule 3 out.
This is an implementation of 2.
In addition, the function handler for fdr more aggressively checks for
finalization and makes an attempt to release its buffer.
Reviewers: pelikan, dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31384
llvm-svn: 298982
Summary:
This change exercises the end-to-end functionality defined in the FDR
logging implementation. We also prepare for being able to run traces
generated by the FDR logging implementation from being analysed with the
llvm-xray command that comes with the LLVM distribution.
This also unblocks D31385, D31384, and D31345.
Reviewers: kpw, pelikan
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31452
llvm-svn: 298977
Summary:
Originally, a few tests fail for armhf target due to:
1) COMPILER_RT_ARMHF_TARGET was not set when building the lib
2) COMPILER_RT_ABI should not be defined as `__attribute__((pcs("aapcs")))` for armhf when building for both lib and tests
This address https://bugs.llvm.org//show_bug.cgi?id=32261
mulsc3_test.c is a newly exposed issue, which will be addressed separately.
Reviewers: rengolin, compnerd
Reviewed By: compnerd
Subscribers: aemerson, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31448
llvm-svn: 298974
Summary:
This prevents InternalAlloc from being called before the sanitizers
are fully initialized.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31306
llvm-svn: 298947
Summary:
Now that __thread is no longer used for lsan on darwin, i386 builds
can be enabled.
Reviewers: kcc, kubamracek
Subscribers: danalbert, srhines, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29995
llvm-svn: 298946
Re-land of r298714 which got reverted in r298868.
It looks like the current lit tests won't run for Apple.
Possible reason is the libname is different. (need to update
the base_lib variable of lit.cfg)
llvm-svn: 298892
Having this function in common seems to trigger a lot of unrelated
test failures. Given that this isn't really common code anyway,
move this to a new linux-specific lsan file.
llvm-svn: 298878
This test case occassionally hangs when run on powerpc. This is also a
problem on AArch64 (see https://bugs.llvm.org/show_bug.cgi?id=24389).
Reactivate this when the problem is fixed.
This could also be related to the same problem as with the tests
ThreadedOneSizeMallocStressTest, ThreadedMallocStressTest, and several
others that do not run reliably on powerpc.
llvm-svn: 298873
On Darwin, we're having multiple issues with using -fomit-frame-pointer in the AddressSanitizer and ThreadSanitizer runtimes, so we're actually not using -fomit-frame-pointer in the our builds of the sanitizer dylibs. This patch just pushes our internal change upstream.
The issues are usually with debuggers, profilers and other tools that unwind the stack (crash reporter), which are often simply not able to get a stack trace. And crashlogs that don't contain a stack trace are a huge problem.
Differential Revision: https://reviews.llvm.org/D31376
llvm-svn: 298859
Summary:
This patch allows us to move away from using __thread on darwin,
which is requiring for building lsan for darwin on ios version 7
and on iossim i386.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31291
llvm-svn: 298848
Summary:
This test fails with a false negative due to an unrelated change.
Since we expect a number of false negatives on 32-bit lsan,
disable this test on linux-i386 and linux-i686.
Reviewers: kubamracek, m.ostapenko, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31300
llvm-svn: 298847
In file included from /home/abuild/rpmbuild/BUILD/llvm/projects/compiler-rt/lib/xray/tests/unit/xray_fdr_log_printer_tool.cc:15:
../projects/compiler-rt/lib/xray/tests/../xray_fdr_logging_impl.h:221:21: error: use of undeclared identifier 'CLOCK_MONOTONIC'
wall_clock_reader(CLOCK_MONOTONIC, &TS);
^
1 error generated.
llvm-svn: 298837
Instead of std::atomic APIs for atomic operations, we instead use APIs
include with sanitizer_common. This allows us to, at runtime, not have
to depend on potentially dynamically provided implementations of these
atomic operations.
Fixes http://llvm.org/PR32274.
llvm-svn: 298833
This is failing on some of our internal bots because we're using different symbolizers. It doesn't seem important and we never test for column numbers in any other tests, so let's just remove it.
Differential Revision: https://reviews.llvm.org/D30122
llvm-svn: 298822
While it's usually a bug to call GCD APIs, such as dispatch_after, with NULL as a queue, this often "somehow" works and TSan should maintain binary compatibility with existing code. This patch makes sure we don't try to call Acquire and Release on NULL queues, and add one such testcase for dispatch_after.
Differential Revision: https://reviews.llvm.org/D31355
llvm-svn: 298820
There are several problems with the current annotations (AnnotateRWLockCreate and friends):
- they don't fully support deadlock detection (we need a hook _before_ mutex lock)
- they don't support insertion of random artificial delays to perturb execution (again we need a hook _before_ mutex lock)
- they don't support setting extended mutex attributes like read/write reentrancy (only "linker init" was bolted on)
- they don't support setting mutex attributes if a mutex don't have a "constructor" (e.g. static, Java, Go mutexes)
- they don't ignore synchronization inside of lock/unlock operations which leads to slowdown and false negatives
The new annotations solve of the above problems. See tsan_interface.h for the interface specification and comments.
Reviewed in https://reviews.llvm.org/D31093
llvm-svn: 298809
Asserting the result of strtok when we expect delimiter overflow is
flaky, the result depends on the random state of memory right after the
delimiters.
llvm-svn: 298743
Summary:
Original r297566 (https://reviews.llvm.org/D30802) is splitted into two parts.
This part adds CMakefile/lit.cfg support.
Reviewers: rengolin, compnerd, jroelofs, erik.pilkington
Subscribers: srhines, dberris, mgorny
Differential Revision: https://reviews.llvm.org/D31259
llvm-svn: 298714
Summary:
Value of __ARM_ARCH_ISA_THUMB isn't based on the actual compilation
mode (-mthumb, -marm), it reflect's capability of given CPU.
Due to this:
- use __tbumb__ and __thumb2__ insteand of __ARM_ARCH_ISA_THUMB
- use '.thumb' directive consistently in all affected files
- decorate all thumb functions using
DEFINE_COMPILERRT_THUMB_FUNCTION()
---------
Note: This patch doesn't fix broken Thumb1 variant of __udivsi3 !
Reviewers: weimingz, rengolin, compnerd
Subscribers: aemerson, dim
Differential Revision: https://reviews.llvm.org/D30938
llvm-svn: 298713
Summary: Fd needs to be closed before the number gets out of scope.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31278
llvm-svn: 298685
Summary:
This change addresses https://github.com/google/sanitizers/issues/766. I
tested the change with make check-asan and the newly added test case.
Reviewers: ygribov, kcc, alekseyshl
Subscribers: kubamracek, llvm-commits
Patch by mrigger
Differential Revision: https://reviews.llvm.org/D30384
llvm-svn: 298650
Summary:
sysconf(_SC_PAGESIZE) is called very early during sanitizer init and
any instrumented code (sysconf() wrapper/interceptor will likely be
instrumented) calling back to sanitizer before init is done will
most surely crash.
2nd attempt, now with glibc version checks (D31092 was reverted).
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D31221
llvm-svn: 298613
Summary:
This patch is the first step towards allows us to move away from using
__thread for the allocator cache on darwin,
which is requiring for building lsan for darwin on ios version 7
and on iossim i386.
This will be followed by patches to move the function into OS-specific files.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29994
llvm-svn: 298537
Summary: Currently, we build the compiler-rt runtimes with link-time optimization if LTO is configured for the LLVM project. This will break external programs that don't invoke the linker in such a way that it supports LLVM's LTO. To avoid this, this change causes the compiler-rt runtimes to be compiled with -fno-lto. This also makes the check-profile tests work on systems when doing a lld LTO build on a system where the system linker does not support LLVM LTO.
Reviewers: rnk, davidxl
Reviewed By: davidxl
Subscribers: dberris, mgorny, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D31218
llvm-svn: 298525
Summary:
Depending on C++11 <system_error> introduces a link-time requirement to
C++11 symbols. Removing it allows us to depend on header-only C++11 and
up libraries.
Partially fixes http://llvm.org/PR32274 -- we know there's more invasive work
to be done, but we're doing it incrementally.
Reviewers: dblaikie, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31233
llvm-svn: 298480
Summary: check_cxx_compiler_flag and check_library_exists could fail because they ignored CMAKE_EXE_LINKER_FLAGS and therefore would always fail to produce executables. Cmake policy CMP0056 fixes this, but was explicitly set to OLD in our CMakeLists because it caused problems with test_target_arch. This change sets the policy to NEW to fix the problem with the compiler and library tests, and temporarily clears CMAKE_EXE_LINKER_FLAGS inside test_target_arch to emulate the old behavior there. This allows, for example, LTO builds that require lld to succeed.
Reviewers: davidxl, beanz
Reviewed By: beanz
Subscribers: fjricci, dberris, mgorny, mehdi_amini, tejohnson, rnk, llvm-commits
Differential Revision: https://reviews.llvm.org/D31098
llvm-svn: 298413
HLE flags can be combined with memory order in atomic operations.
Currently tsan runtime crashes on e.g. IsStoreOrder(mo) in atomic store
if any of these additional flags are specified.
Filter these flags out.
See the comment as to why it is safe.
llvm-svn: 298378
Original r297566 is splitted into two parts.
This is part one, which adds "RUN" command for test cases.
Unit/arm/call_apsr.S is updated to support thumb1.
It also fixes a bug in arm/aeabi_uldivmod_test.c
gcc_personality_test is XFAILED as the framework cannot handle it so far.
cpu_model_test is also XFAILED for now as it is expected to return non-zero.
TODO: A few tests are XFAILed for armhf and aarch64.
We need further investigating. [1,2] Tracks the issue.
[1] https://bugs.llvm.org//show_bug.cgi?id=32260
[2] https://bugs.llvm.org//show_bug.cgi?id=32261
Reviewers: rengolin, compnerd, jroelofs, erik.pilkington, arphaman
Reviewed By: jroelofs
Subscribers: jroelofs, aemerson, srhines, nemanjai, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30802
llvm-svn: 298339
Summary:
sysconf(_SC_PAGESIZE) is called very early, during sanitizer init and
any instrumented code (a wrapper/interceptor will likely be instrumented)
calling back to sanitizer before init is done will most surely crash.
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D31092
llvm-svn: 298305
Revert "Fix sanitizer tests with LLVM_TOOL_LLD_BUILD=OFF."
Revert "[asan] Remove gc-sections test with bfd."
Revert "[asan] Disable globals-gc test with ld.bfd."
Revert "[asan] Fix dead stripping of globals on Linux (compiler-rt)"
OOM in gold linker.
llvm-svn: 298287
Summary:
This patch allows us to move away from using __thread on darwin,
which is requiring for building lsan for darwin on ios version 7
and on iossim i386.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29994
llvm-svn: 298274
Summary:
This patch allows us to move away from using __thread on darwin,
which is requiring for building lsan for darwin on ios version 7
and on iossim i386.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29994
llvm-svn: 298214
It used to be XFAIL: *, but with the new implementation it passes in some cases
and fails in other. There are similar tests for gold and lld that are not
flaky, and a positive test for bfd that makes sure that were are not breaking
existing functionality.
llvm-svn: 298173
Runtime support for the new instrumentation of globals based on !associated, and a bunch of tests.
Differential Revision: https://reviews.llvm.org/D30120
llvm-svn: 298159
And also r295364 [PGO] remove unintended debug trace. NFC
I removed the test case: it's hard to write synchronized test b/w processes
in this framework. I will revisit the test-case later.
llvm-svn: 298113
This patch adds profile run time support to profile a range of values.
This interface will be used in profiling the size of memory intrinsic calls.
Differential Revision: http://reviews.llvm.org/D28964
llvm-svn: 297895
Summary: The CHECK failed when the name is __interceptor_wcsncpy
Reviewers: bkramer, eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30975
llvm-svn: 297828
Summary:
Separated the IO and the thread local storage state machine of logging
from the writing of log records once the contents are deterministic.
Finer granularity functions are provided as inline functions in the same
header such that stack does not grow due to the functions being separated.
An executable utility xray_fdr_log_printer is also implemented to use the
finest granularity functions to produce binary test data in the FDR format
with a relatively convenient text input.
For example, one can take a file with textual contents layed out in rows
and feed it to the binary to generate data that llvm-xray convert can then
read. This is a convenient way to build a test suite for llvm-xray convert
to ensure it's robust to the fdr format.
Example:
$cat myFile.txt
NewBuffer : { time = 2 , Tid=5}
NewCPU : { CPU =1 , TSC = 123}
Function : { FuncId = 5, TSCDelta = 3, EntryType = Entry }
Function : { FuncId = 5, TSCDelta = 5, EntryType = Exit}
TSCWrap : { TSC = 678 }
Function : { FuncId = 6, TSCDelta = 0, EntryType = Entry }
Function : { FuncId = 6, TSCDelta = 50, EntryType = Exit }
EOB : { }
$cat myFile.txt | ./bin/xray_fdr_log_printer > /tmp/binarydata.bin
$./bin/llvm-xray convert -output-format=yaml -output=- /tmp/binarydata.bin
yaml format comes out as expected.
Reviewers: dberris, pelikan
Reviewed By: dberris
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30850
llvm-svn: 297801
Summary:
Use TSC emulation in cases where RDTSCP isn't available on the host
running an XRay instrumented binary. We can then fall back into
emulation instead of not even installing XRay's runtime functionality.
We only do this for now in the naive/basic logging implementation, but
should be useful in even FDR mode.
Should fix http://llvm.org/PR32148.
Reviewers: pelikan, rnk, sdardis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30677
llvm-svn: 297800
check for the existence of RTLD_DEEPBIND, since this constant is only
supported for glibc >= 2.3.4. This fixes builds for FreeBSD and other
platforms that do not have RTLD_DEEPBIND.
llvm-svn: 297763
symbols dynamically
The CoreFoundation symbols uses by __isOSVersionAtLeast should be loaded at
runtime to ensure that the programs that don't use @available won't have to be
linked to CoreFoundation.
The Clang frontend IRGen library will need to emit a CoreFoundation symbol
when @available is used to ensure that programs that actually use @available
are linked to CoreFoundation.
rdar://31039554
llvm-svn: 297760
Add 'nullability_arg' and 'nullability_return' diagnostic handlers, and
also add a TypeCheckKind for null assignments to _Nonnull. With this in
place, we can update clang to use the nicer handlers for nullability
diagnostics.
The alternative to this approach is to update the existing 'nonnull_arg'
and 'nonnull_return' handlers to accept a boolean parameter. However,
versioning the existing handlers would cause code size bloat, and the
complexity cost of introducing new handlers into the runtime is low.
I will add tests for this, and all of -fsanitize=nullability, into
check-ubsan once the clang side of the changes is in.
llvm-svn: 297748
Summary: This is useful in some platforms where one of these signals is special.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30783
llvm-svn: 297665
Summary:
This patch implements a initial support of lit test for builtins.
Unit/arm/call_apsr.S is updated to support thumb1.
It also fixes a bug in arm/aeabi_uldivmod_test.c
gcc_personality_test is XFAILED as the framework cannot handle it so far.
cpu_model_test is also XFAILED for now as it is expected to return non-zero.
Reviewers: rengolin, compnerd, jroelofs, erik.pilkington, arphaman
Reviewed By: jroelofs
Subscribers: jroelofs, aemerson, srhines, nemanjai, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30802
llvm-svn: 297566
This predicate compares the host's marketing OS version to one passed as
argument. Currently, only darwin targets are supported. This is done by parsing
the SystemVersion.plist file.
Also added in this patch is some lit testing infrastructure for builtins, which
previously had none. This part of the patch was written by Alex Lorenz (with
some minor modifications).
This patch is part of a feature I proposed here:
http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html
Differential revision: https://reviews.llvm.org/D30136
llvm-svn: 297382
People keep hitting on spurious failures in malloc/free routines when using sanitizers
with shared libraries dlopened with RTLD_DEEPBIND (see https://github.com/google/sanitizers/issues/611 for details).
Let's check for this flag and bail out with warning message instead of failing in random places.
Differential Revision: https://reviews.llvm.org/D30504
llvm-svn: 297370
There are two possible return values for strerror_r:
On OS X, the return value is always `int`.
On Linux, the return value can be either `char *` or `int`, depending
on the value of:
`(_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE`
Because OS X interceptors require a matching function signature,
split out the two cases into separate interceptors, using the above
information to determine the correct signature for a given build.
llvm-svn: 297315
Summary:
rL297000 and rL297003 implemented arg1 logging on amd64 and made
other architectures build. We need to blacklist the new test as well.
Reviewers: dberris, timshen
Reviewed By: dberris
Subscribers: sdardis, llvm-commits
Differential Revision: https://reviews.llvm.org/D30635
llvm-svn: 297238
Temporarily mark the test as unsupported so the powerpc le buildbot
testers can get back to work.
There was a brief discussion of this on the mailing list for r296998.
llvm-svn: 297184
rL297000 forgot to include code for three architectures that appeared
since I wrote the first version. This gives them the same treatment as ARMs
have for now - write stubs and wait for someone to actually implement it.
Patched by pelikan (Martin Pelikán)!
Differential Revision: https://reviews.llvm.org/D30634
llvm-svn: 297003
Summary:
Functions with the LOG_ARGS_ENTRY sled kind at their beginning will be handled
in a way to (optionally) pass their first call argument to your logging handler.
For practical and performance reasons, only the first argument is supported, and
only up to 64 bits.
Reviewers: javed.absar, dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29703
llvm-svn: 297000
Summary:
Asan is now working on windows 64-bit.
This patch is turning on the unittest.
Reviewers: rnk
Reviewed By: rnk
Subscribers: kubamracek, dberris, beanz, mgorny, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D24742
llvm-svn: 296878
Summary:
This patch allows us to move away from using __thread on darwin,
which is requiring for building lsan for darwin on ios version 7
and on iossim i386.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29994
llvm-svn: 296707
Summary:
The current size is flaky, as revealed by checking
the stack size attr after setting it.
Reviewers: kubamracek, rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30267
llvm-svn: 296706
Summary: Points the user to look at function pointer assignments.
Reviewers: kcc, eugenis, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30432
llvm-svn: 296653
Summary:
Use a common definition of a "this variable is unused" annotation for useless
variables only present for their lambda global initializers, to silence gcc's
warning.
Reviewers: dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29860
llvm-svn: 296449
Summary:
Currently, we assume that applications built with XRay would like to
have the instrumentation sleds patched before main starts. This patch
changes the default so that we do not patch the instrumentation sleds
before main. This default is more helpful for deploying applications in
environments where changing the current default is harder (i.e. on
remote machines, or work-pool-like systems).
This default (not to patch pre-main) makes it easier to selectively run
applications with XRay instrumentation enabled, than with the current
state.
Reviewers: echristo, timshen
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D30396
llvm-svn: 296445
Summary: Points the user to look at function pointer assignments.
Reviewers: kcc, eugenis, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30432
llvm-svn: 296419
Summary:
If symbolizer was instrumented with sanitizer and crash, it may
try to call itself again causing infinite recursion of crashing processes.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D30222
llvm-svn: 295771
This test has been reverted in r279918 due to flaky atos support in the OS
some machines in the buildbot fleet were running. This should not be a
problem anymore.
llvm-svn: 295766
Summary:
The DLL thunks are stubs added to an instrumented DLL to redirect ASAN API calls
to the real ones in the main executable. These thunks must contain dummy
code before __asan_init got called. Unfortunately, MSVC linker is doing ICF and is
merging functions with the same body.
In our case, this two ASAN thunks were incorrectly merged:
```
asan_interface.inc:16
INTERFACE_FUNCTION(__asan_before_dynamic_init)
```
```
sanitizer_common_interface.inc:16
INTERFACE_FUNCTION(__sanitizer_verify_contiguous_container)
```
The same thunk got patched twice. After the second patching, calls to
`__asan_before_dynamic_init` are redirected to `__sanitizer_verify_contiguous_container`
and trigger a DCHECK on incorrect operands/
The problem was caused by the macro that is only using __LINE__ to prevent
collapsing code.
```
#define INTERCEPT_SANITIZER_FUNCTION(name)
extern "C" __declspec(noinline) void name() {
volatile int prevent_icf = (__LINE__ << 8); (void)prevent_icf;
```
The current patch is adding __COUNTER__ which is safer than __LINE__.
Also, to precent ICF (guarantee that code is different), we are using a unique attribute:
- the name of the function
Reviewers: rnk
Reviewed By: rnk
Subscribers: llvm-commits, kubamracek, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D30219
llvm-svn: 295761
To avoid depending on kernel headers, we just repeat the single define
we need, which is likely never going to change.
Patch by Joakim Sindholt <opensource@zhasha.com>
llvm-svn: 295738
Summary: On windows 10, the ucrt DLL is performing allocations before the function hooking and there are multiple allocations not handled by Asan. When a free occur at the end of the process, asan is reporting desallocations not malloc-ed.
Reviewers: rnk, kcc
Reviewed By: rnk, kcc
Subscribers: kcc, llvm-commits, kubamracek, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D25946
llvm-svn: 295730
Summary:
Currently, defaulted options cannot be overriden easily. As an example,
we always patch the binary pre-main unless the user defines the option
at the commandline to inhibit this behaviour. This change allows for
building different versions of the XRay archive with different defaults
(whether to patch pre-main, or whether to use FDR mode by default, etc.)
and giving that choice at link-time.
For now we don't create different archives that have different defaults,
but those could be added in later revisions. This change just enables
the possibility.
Reviewers: pelikan, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30022
llvm-svn: 295534
Summary:
These sanitizers are enabled and used in Android but got built with
Android's build system. This change enables them in the CMake build
system.
Reviewers: eugenis
Subscribers: llvm-commits, danalbert, srhines, mgorny
Differential Revision: https://reviews.llvm.org/D30127
llvm-svn: 295523
Summary:
This patch allows us to move away from using __thread on darwin,
which is requiring for building lsan for darwin on ios version 7
and on iossim i386.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29994
llvm-svn: 295413
Summary:
Version 8 is the first version to support the __thread
keyword, which is required for building lsan for
64-bit ios.
Reviewers: kubamracek, kcc, glider
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29787
llvm-svn: 295412
Summary:
__thread is not supported by all darwin versions and architectures,
use pthreads instead to allow for building darwin lsan on iossim.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29993
llvm-svn: 295405
Summary:
We found a nondeterministic behavior when doing online profile merging
for multi-process applications. The application forks a sub-process and
sub-process sets to get SIGKILL when the parent process exits,
The first process gets the lock, and dumps the profile. The second one
will mmap the file, do the merge and write out the file. Note that before
the merged write, we truncate the profile.
Depending on the timing, the child process might be terminated
abnormally when the parent exits first. If this happens:
(1) before the truncation, we will get the profile for the main process
(2) after the truncation, and before write-out the profile, we will get
0 size profile.
(3) after the merged write, we get merged profile.
This patch temporarily suspend the SIGKILL for PR_SET_PDEATHSIG
before profile-write and restore it after the write.
This patch only applies to Linux system.
Reviewers: davidxl
Reviewed By: davidxl
Subscribers: xur, llvm-commits
Differential Revision: https://reviews.llvm.org/D29954
llvm-svn: 295364
In D28836, we added a way to tag heap objects and thus provide object types into report. This patch exposes this information into the debugging API.
Differential Revision: https://reviews.llvm.org/D30023
llvm-svn: 295318
Summary:
Add in #ifdef to exclude cpu_model_test on non-X86 and *vfp_test on ARM targets without VFP support.
This is consistent with other target-specific tests that print "Skipped" if not supported.
Reviewers: rengolin, compnerd, asbirlea
Reviewed By: compnerd
Subscribers: llvm-commits, aemerson
Differential Revision: https://reviews.llvm.org/D29882
llvm-svn: 295261
Summary:
Coverage is using large arrays which requires large allocations.
These allocations are flaky and often failing on win64.
We are using the 32-bits size until this gets a better fix.
Reviewers: rnk
Reviewed By: rnk
Subscribers: llvm-commits, kubamracek, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D29945
llvm-svn: 295086
Summary:
There is no guarantee that the tls_init is executed on the static runtime
(/MT).
On windows 7, this unittest is failing.
On windows 10, I believe it's working because of the new CRT.
On ASAN side, it doesn't matter that the hook point is run or not.
It must be run only if there is other tls_initializer that are registered.
Reviewers: rnk, chrisha
Reviewed By: rnk
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D29838
llvm-svn: 295057
Summary:
Adds a new cmake flag 'COMPILER_RT_ENABLE_LSAN_OSX', which enables lsan
compilation and is turned off by default. Patches to fix build errors
when this flag is enabled will be uploaded soon.
This is part of an effort to port LSan to OS X, but LSan on OS X does not
currently work or pass tests currently.
Reviewers: kubamracek, kcc, glider, alekseyshl
Reviewed By: kubamracek
Subscribers: danalbert, srhines, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29783
llvm-svn: 295012
Summary:
__thread is supported on Darwin, but is implemented dynamically via
function calls to __tls_get_addr. This causes two issues when combined
with leak sanitizer, due to malloc() interception.
- The dynamic loader calls malloc during the process of loading
the sanitizer dylib, while swapping a placeholder tlv_boostrap
function for __tls_get_addr. This will cause tlv_bootstrap to
be called in DisabledInThisThread() via the asan allocator.
- The first time __tls_get_addr is called, it allocates memory
for the thread-local object, during which it calls malloc(). This
call will be intercepted, leading to an infinite loop in the asan
allocator, in which the allocator calls DisabledInThisThread,
which calls tls_get_addr, which calls into the allocator again.
Reviewers: kcc, glider, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29786
llvm-svn: 294994
Summary:
This patch provides stubs for all of the lsan platform-specific
functions which need to be implemented for darwin. Currently
all of these functions are stubs, for the purpose of fixing
compilation.
Reviewers: kcc, glider, kubamracek
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29784
llvm-svn: 294983
Revert "Fix -Wsign-compare - this might not be quite right, but preserves behavior"
Revert "[XRay] Implement powerpc64le xray."
This reverts commit r294826.
This reverts commit r294781.
llvm-svn: 294842
Summary:
Since struct rtentry is an internal kernel-only structure on FreeBSD,
and SIOCADDRT and SIOCDELRT are not supported anyway, stop including
socketvar.h and attempting to get at the definition of struct rtentry,
and move the line with struct_rtentry_sz to the SANIZER_LINUX block.
Reviewers: kcc, kutuzov.viktor.84, emaste
Reviewed By: kcc, emaste
Subscribers: emaste, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D29832
llvm-svn: 294806
Summary: This patch adds whitelist for RHEL6 and RHEL7 kernels that are known to have the CVE fixed.
Reviewers: koriakin, kcc
Reviewed By: kcc
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D29825
llvm-svn: 294799
Summary:
GET_CALLER_PC doesn't work properly on 31-bit s390, as pointers are 31-bit, the MSB bit can be set when the return address is copied into integer.
This causes e.g. errors like:
#0 0xfdadb129 (<unknown module>)
#1 0x7da5e1d1 in __asan::GetStackTraceWithPcBpAndContext(__sanitizer::BufferedStackTrace*, unsigned long, unsigned long, unsigned long, void*, bool) ../../../../../libsanitizer/asan/asan_stack.h:50
#2 0x7da5e1d1 in __asan::ErrorGeneric::Print() ../../../../../libsanitizer/asan/asan_errors.cc:482
#3 0x7db178d5 in __asan::ErrorDescription::Print() ../../../../../libsanitizer/asan/asan_errors.h:360
#4 0x7db178d5 in __asan::ScopedInErrorReport::~ScopedInErrorReport() ../../../../../libsanitizer/asan/asan_report.cc:167
#5 0x7db178d5 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) ../../../../../libsanitizer/asan/asan_report.cc:397
#6 0x7dadb14f in __interceptor_memcmp ../../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:626
#7 0x400cf5 in main /home/jakub/gcc/gcc/testsuite/c-c++-common/asan/memcmp-1.c:14
#8 0x7d807215 in __libc_start_main (/lib/libc.so.6+0x1a215)
#9 0x4007ed (/home/jakub/gcc/obj/gcc/testsuite/memcmp-1.exe+0x4007ed)
The actual return PC inside __interceptor_memcmp was 0x7dadb129 rather than 0xfdadb129.
Reviewers: koriakin, kcc
Reviewed By: kcc
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D29824
llvm-svn: 294793
Summary:
Symbol __tls_get_addr_internal is a GLIBC_PRIVATE private symbol on s390{,x}, the glibc folks aren't very happy about asan using it.
Additionally, only recent glibc versions have it, older versions just have __tls_get_offset and nothing else.
The patch doesn't drop the __tls_get_addr_internal interception altogether, but changes it so that it calls real __tls_get_offset function instead (and much more importantly,
that __tls_get_offset interception calls the real __tls_get_offset function).
This way it should work also on glibc 2.18 and earlier. See http://gcc.gnu.org/PR79341 for further details.
Reviewers: kcc, koriakin
Reviewed By: kcc, koriakin
Subscribers: kubamracek, mehdi_amini
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D29735
llvm-svn: 294790
Summary:
powerpc64 big-endian is not supported, but I believe that most logic can
be shared, except for xray_powerpc64.cc.
Also add a function InvalidateInstructionCache to xray_util.h, which is
copied from llvm/Support/Memory.cpp. I'm not sure if I need to add a unittest,
and I don't know how.
Reviewers: dberris, echristo, iteratee, kbarton, hfinkel
Subscribers: mehdi_amini, nemanjai, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29742
llvm-svn: 294781
Summary:
The implementation, however, is in different arch-specific files, unless it's emulated.
Reviewers: dberris, pelikan, javed.absar
Subscribers: aemerson, llvm-commits
Differential Revision: https://reviews.llvm.org/D29796
llvm-svn: 294777
Summary:
This patch unifies the behavior of BlockingMutex on linux and mac,
resolving problems that can arise when BlockingMutex is used in
code shared by the two platforms but has different behavior depending
on the platform.
No longer requires that the calling thread own the mutex for
CheckLocked calls to pass.
Reviewers: dvyukov, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29728
llvm-svn: 294614
Summary:
Fixing a bug I found when testing a reader for the FDR format. Function ID is
now correctly packed into the 28 bits which are documented for it instead of being
masked to all ones.
Reviewers: dberris, pelikan, eugenis
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29698
llvm-svn: 294563
When building for Windows, we would check if we were using MSVC rather
than WIN32. This resulted in needed targets not being defined by
sanitizer_common. Fix the conditional.
When registering the objects libraries for ASAN, we would multiply
register for all targets as we were creating them inside a loop over all
architectures. Only define the target per architecture.
llvm-svn: 294510
Summary: lib/sanitizer_common/sanitizer_win_defs.h defineds WINAPI, which is also defined by standard Windows headers. Redefining it causes warnings during compilation. This change causes us to only define WINAPI if it is not already defined, which avoids the warnings.
Reviewers: rnk, zturner, mpividori
Reviewed By: rnk, mpividori
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D29683
llvm-svn: 294497
Add an #if that excludes the newly added aeabi* tests on non-ARM
platforms. This is consistent with other ARM tests, and aims to make
running builtin tests easier. Lacking a proper infrastructure to run
tests selectively, it is more convenient if we do not have to implement
directory-platform exclusions and can just rely on tests compiling to
no-op on other platforms.
Differential Revision: https://reviews.llvm.org/D29708
llvm-svn: 294438
Add support for weak hooks on Windows, as we do on Linux and Darwin.
As we use the macro: `SANITIZER_INTERFACE_WEAK_DEF()` it was not necessary to
modify the header file: `sanitizer_common_interceptors.h`.
After this diff, many tests were fixed for libFuzzer.
Differential Revision: https://reviews.llvm.org/D29562
llvm-svn: 294409
Summary:
As pointed out in casual reading of the XRay codebase, that we had
some interesting named functions that didn't quite follow the LLVM coding
conventions.
Reviewers: chandlerc, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29625
llvm-svn: 294373
With universal_newlines, readline() stalls to fill the buffer. Therefore, let the pipe unbuffered.
This is part of https://reviews.llvm.org/D27404
FIXME: Use Popen.communicate()
llvm-svn: 294303
Summary:
Apparently "test standalone compiler-rt" still requires -ldl and -lrt for
Scudo even with --gc-sections. I am not entirely sure why, so if anybody has
some input, feel free to chime in.
In the meantime, add again those two to fix the test.
Reviewers: kcc, alekseyshl
Reviewed By: kcc
Subscribers: Hahnfeld, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D29527
llvm-svn: 294199
Summary:
This patch implements addsf3/__aeabi_fadd in asm for Thumb1.
Compared with generic C version (lib/fp_add_impl.inc), it
1. all constants are materialized instead of loading from constant pool
2. no stack spills (C version uses 136 bytes stack space)
3. clz() is called only when necessary. (C version always calls it)
Reviewers: compnerd, rengolin, asl
Reviewed By: asl
Subscribers: efriedma, aemerson, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29485
llvm-svn: 294172
Summary:
This was pointed out that FDR mode didn't quite put the thread ID in the
buffers, but instead would write down the parent process ID.
Reviewers: pelikan, rSerge
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29484
llvm-svn: 294166
Summary:
The assumption __sanitizer_get_heap_size() == 0 (introduced in D29341) at the
start of a program appears to be incorrect on some ARM machines
(SizeClassAllocator32).
This should fix the test while I investigate the issue.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D29516
llvm-svn: 294056
Summary:
The local and global quarantine sizes were not offering a distinction for
32-bit and 64-bit platforms. This is addressed with lower values for 32-bit.
When writing additional tests for the quarantine, it was discovered that when
calling some of the allocator interface function prior to any allocation
operation having occured, the test would crash due to the allocator not being
initialized. This was addressed by making sure the allocator is initialized
for those scenarios.
Relevant tests were added in interface.cpp and quarantine.cpp.
Last change being the removal of the extraneous link dependencies for the
tests thanks to rL293220, anf the addition of the gc-sections linker flag.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29341
llvm-svn: 294037
This test relies on sanitizer common interceptor to pick the oldest version of
sem_init function from Glibc. But LSan actually doesn't intercept sem_init, thus
the new implementation is called that causes test failure. Disable it for LSan x86,
the proper fix would require to check Glibc version at runtime and adjust
GET_SEM_VALUE(V) accordingly.
llvm-svn: 294001
On Windows, the symbols "___stop___sancov_guards" and "___start___sancov_guards"
are not defined automatically. So, we need to take a different approach.
We define 3 sections: ".SCOV$A", ".SCOV$M" and ".SCOV$Z".
Section ".SCOV$A" will only hold a variable ___start___sancov_guard.
Section ".SCOV$M" will hold the main data.
Section ".SCOV$Z" will only hold a variable ___stop___sancov_guards.
When linking, they will be merged sorted by the characters after the $, so we
can use the pointers of the variables ___[start|stop]___sancov_guard to know the
actual range of addresses of that section.
___[start|stop]___sancov_guard should be defined only once per module. On
Windows, we have 2 different cases:
+ When considering a shared runtime:
All the modules, main executable and dlls, are linked to an auxiliary static
library dynamic_runtime_thunk.lib. Because of that, we include the delimiters
in `SancovDynamicRuntimeThunk`.
+ When considering a static runtime:
The main executable in linked to the static runtime library.
All the dlls are linked to an auxiliary static library dll_thunk.
Because of that, we include the delimiter to both `SancovDllThunk` and
`SANITIZER_LIBCDEP_SOURCES` (which is included in the static runtime lib).
Differential Revision: https://reviews.llvm.org/D28435
llvm-svn: 293959
In Windows, when sanitizers are implemented as a shared library (DLL), users can
redefine and export a new definition for weak functions, in the main executable,
for example:
extern "C" __declspec(dllexport)
void __sanitizer_cov_trace_pc_guard(u32* guard) {
// Different implementation provided by the client.
}
However, other dlls, will continue using the default implementation imported
from the sanitizer dll. This is different in linux, where all the shared
libraries will consider the strong definition.
With the implementation in this diff, when the dll is initialized, it will check
if the main executable exports the definition for some weak function (for
example __sanitizer_cov_trace_pc_guard). If it finds that function, then it will
override the function in the dll with that pointer. So, all the dlls with
instrumentation that import __sanitizer_cov_trace_pc_guard__dll() from asan dll,
will be using the function provided by the main executable.
In other words, when the main executable exports a strong definition for a weak
function, we ensure all the dlls use that implementation instead of the default
weak implementation.
The behavior is similar to linux. Now, every user that want to override a weak
function, only has to define and export it. The same for Linux and Windows, and
it will work fine. So, there is no difference on the user's side.
All the sanitizers will include a file sanitizer_win_weak_interception.cc that
register sanitizer's weak functions to be intercepted in the binary section WEAK
When the sanitizer dll is initialized, it will execute weak_intercept_init()
which will consider all the CB registered in the section WEAK. So, for all the
weak functions registered, we will check if a strong definition is provided in
the main executable.
All the files sanitizer_win_weak_interception.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we include [asan|ubsan|sanitizer_coverage]_win_weak_interception.cc and
sanitizer_win_weak_interception.cc in asan dll, so when it is initialized, it
will consider all the weak functions from asan, ubsan and sanitizer coverage.
After this diff, sanitizer coverage is fixed for MD on Windows. In particular
libFuzzer can provide custom implementation for all sanitizer coverage's weak
functions, and they will be considered by asan dll.
Differential Revision: https://reviews.llvm.org/D29168
llvm-svn: 293958
In this diff I update the code for asan on Windows, so we can intercept
SetUnhandledExceptionFilter and catch some exceptions depending on the result of
IsHandledDeadlyException() (which depends on asan flags).
This way we have the same behavior on Windows and Posix systems.
On Posix, we intercept signal and sigaction, so user's code can only register
signal handlers for signals that are not handled by asan.
After this diff, the same happens on Windows, user's code can only register
exception handlers for exceptions that are not handled by asan.
Differential Revision: https://reviews.llvm.org/D29463
llvm-svn: 293957
In Windows, when the sanitizer is implemented as a shared library (DLL), we need
an auxiliary static library dynamic_runtime_thunk that will be linked to the
main executable and dlls.
In the sanitizer DLL, we are exposing weak functions with WIN_WEAK_EXPORT_DEF(),
which exports the default implementation with __dll suffix. For example: for
sanitizer coverage, the default implementation of __sanitizer_cov_trace_cmp is
exported as: __sanitizer_cov_trace_cmp__dll.
In the dynamic_runtime_thunk static library, we include weak aliases to the
imported implementation from the dll, using the macro WIN_WEAK_IMPORT_DEF().
By default, all users's programs that include calls to weak functions like
__sanitizer_cov_trace_cmp, will be redirected to the implementation in the dll,
when linking to dynamic_runtime_thunk.
After this diff, we are able to compile code with sanitizer coverage
instrumentation on Windows. When the instrumented object files are linked with
clang-rt_asan_dynamic_runtime_thunk-arch.lib all the weak symbols will be
resolved to the implementation imported from asan dll.
All the files sanitizer_dynamic_runtime_thunk.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we compile: [asan|ubsan|sanitizer_coverage]_win_dynamic_runtime_thunk.cc
and sanitizer_win_dynamic_runtime_thunk.cc to generate
asan_dynamic_runtime_thunk.lib, because we include asan, ubsan and sanitizer
coverage in the address sanitizer library.
Differential Revision: https://reviews.llvm.org/D29158
llvm-svn: 293953
In this diff, I update current implementation of the interception in dll_thunks
to consider the special case of weak functions.
First we check if the client has redefined the function in the main executable
(for example: __sanitizer_cov_trace_pc_guard). It we can't find it, then we look
for the default implementation (__sanitizer_cov_trace_pc_guard__dll). The
default implementation is always available because the static runtime is linked
to the main executable.
Differential Revision: https://reviews.llvm.org/D29155
llvm-svn: 293952
When the sanitizer is implemented as a static library and is included in the
main executable, we need an auxiliary static library dll_thunk that will be
linked to the dlls that have instrumentation, so they can refer to the runtime
in the main executable. Basically, it uses interception to get a pointer the
function in the main executable and override its function with that pointer.
Before this diff, all of the implementation for dll_thunks was included in asan.
In this diff I split it into different sanitizers, so we can use other
sanitizers regardless of whether we include asan or not.
All the sanitizers include a file sanitizer_win_dll_thunk.cc that register
functions to be intercepted in the binary section: DLLTH
When the dll including dll_thunk is initialized, it will execute
__dll_thunk_init() implemented in: sanitizer_common/sanitizer_win_dll_thunk.cc,
which will consider all the CB registered in the section DLLTH. So, all the
functions registered will be intercepted, and redirected to the implementation
in the main executable.
All the files "sanitizer_win_dll_thunk.cc" are independent, so we don't need to
include a specific list of sanitizers. Now, we compile: asan_win_dll_thunk.cc
ubsan_win_dll_thunk.cc, sanitizer_coverage_win_dll_thunk.cc and
sanitizer_win_dll_thunk.cc, to generate asan_dll_thunk, because we include asan,
ubsan and sanitizer coverage in the address sanitizer library.
Differential Revision: https://reviews.llvm.org/D29154
llvm-svn: 293951
This test fails consistently on Ubuntu 16.xx powerpc64 LE systems.
The cause is being investigated and in the meantime disable it so
the buildbots can run cleanly.
llvm-svn: 293939
This patch allows a non-instrumented library to call into TSan runtime, and tell us about "readonly" and "modifying" accesses to an arbitrary "object" and provide the caller and tag (type of object). This allows TSan to detect violations of API threading contracts where "read-only" methods can be called simulatenously from multiple threads, while modifying methods must be exclusive.
Differential Revision: https://reviews.llvm.org/D28836
llvm-svn: 293885
When dealing with GCD worker threads, TSan currently prints weird things like "created by thread T-1" and "[failed to restore the stack]" in reports. This patch avoids that and instead prints "Thread T3 (...) is a GCD worker thread".
Differential Revision: https://reviews.llvm.org/D29103
llvm-svn: 293882
Summary:
In llvm.org/PR31756 it's pointed out that sometimes rdtscp isn't
available. We fix it here by checking first whether it's availble before
installing the logging handler. In future commits we can have
alternative implementations, maybe working around some of the
constraints on some systems.
This change enables us to make that determination, but report an error
instead when the features aren't available.
Reviewers: sdardis, javed.absar, rSerge
Subscribers: pelikan, llvm-commits
Differential Revision: https://reviews.llvm.org/D29438
llvm-svn: 293870
After this commint, we can include sancov_flags.h and refer to
__sancov_default_options without requiring the namespace prefix.
Differential Revision: https://reviews.llvm.org/D29167
llvm-svn: 293731
We ignore `__ubsan_handle_dynamic_type_cache_miss*` symbols when
`SANITIZER_CAN_USE_CXXABI` is true. Because they are included in the
library but they are not included in the interface lists.
llvm-svn: 293711
The test was failing because we export the functions: "__sanitizer_mz*" but they
are not included in the general interface lists.
Also, weak undefined symbols are tagged with U by `nm -g` on Darwin.
Differential Revision: https://reviews.llvm.org/D29345
llvm-svn: 293710
Add a new auxiliary file to each sanitizer: sanitizer_interface.inc, listing all
the functions exported, with the macros: INTERFACE_FUNCTION() and
INTERFACE_WEAK_FUNCTION().
So, when we need to define or repeat a procedure for each function in the
sanitizer's interface, we can define the macros and include that header.
In particular, these files are needed for Windows, in the nexts commits.
Also, this files could replace the existing files: weak_symbols.txt for Apple.
Instead of reading weak_symbols.txt to get the list of weak symbols, we could
read the file sanitizer_interface.inc and consider all the symbols included with
the macro INTERFACE_WEAK_FUNCTION(Name).
In this commit, I only include these files to the sanitizers that work on
Windows. We could do the same for the rest of the sanitizers when needed.
I updated tests for: Linux, Darwin and Windows. If a new function is exported
but is not present in the interface list, the tests
"interface_symbols_[darwin|windows|linux].c" fail.
Also, I remove the comments: "/* OPTIONAL */" which are not required any more,
because we use the macro: INTERFACE_WEAK_FUNCTION() for weak functions.
Differential Revision: https://reviews.llvm.org/D29148
llvm-svn: 293682
Summary:
g_tls_size is not supposed to be changed after initialization. It's not
atomic, not guarded by a lock, nor thread_local. But it's read by
multiple threads.
The reason why it's mutated is mips and powerpc64 specific. We can
implement the same funcitonality without mutating g_tls_size.
I'm not sure how to write a test for this. Please advice. Thanks!
Reviewers: eugenis, kcc
Subscribers: kubamracek, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D29236
llvm-svn: 293586
Summary:
For a reason that hasn't been investigated for lack of powerpc knowledge and
hardware, -fno-function-sections is required for the Sanitizers to work
properly on powerpc64le. Without, the function-sections-are-bad test fails on
that architecture (and that architecture only).
This patch re-enables the flag in the powerpc64le cflags.
I have to admit I am not entirely sure if my way is the proper way to do this,
so if anyone has a better way, I'll be happy to oblige.
Reviewers: kcc, eugenis
Reviewed By: eugenis
Subscribers: nemanjai, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29285
llvm-svn: 293558
macOS
Summary:
In https://bugs.freebsd.org/215125 I was notified that some configure
scripts attempt to test for the Linux-specific `mallinfo` and `mallopt`
functions by compiling and linking small programs which references the
functions, and observing whether that results in errors.
FreeBSD and macOS do not have the `mallinfo` and `mallopt` functions, so
normally these tests would fail, but when sanitizers are enabled, they
incorrectly succeed, because the sanitizers define interceptors for
these functions. This also applies to some other malloc-related
functions, such as `memalign`, `pvalloc` and `cfree`.
Fix this by not intercepting `mallinfo`, `mallopt`, `memalign`,
`pvalloc` and `cfree` for FreeBSD and macOS, in all sanitizers.
Also delete the non-functional `cfree` wrapper for Windows, to fix the
test cases on that platform.
Reviewers: emaste, kcc, rnk
Subscribers: timurrrr, eugenis, hans, joerg, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D27654
llvm-svn: 293536
Summary:
in aeabi_ldivmod and uldivmod, using r6 instead of r12 as the temp reg due to limitation of Thumb1 ISA.
Now, all EABI sources are Thumb1 compatible.
Also added test cases by reusing the test cases from divmodsi4_test.c, udivmodsi4_test and udivmoddi4_test.c
Reviewers: rengolin, compnerd
Reviewed By: rengolin
Subscribers: javed.absar, aemerson, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29226
llvm-svn: 293527
This fix a bug, when calling InternalGetProcAddress() for an executable that
doesn't export any symbol. So the table is empty.
If we don't check for this condition, the program fails with Error 0xc0000142.
Also, I add a regression test for Windows.
Differential Revision: https://reviews.llvm.org/D28502
llvm-svn: 293521
Add "OPTIONAL" comment to declaration of weak function in the internal
interface. This fix the tests `interface_symbols_linux.c` and
`interface_symbols_darwin.c` which were failing after r293423.
llvm-svn: 293442
Update the headers, so we can change the dllexports to dllimport when
defining SANITIZER_IMPORT_INTERFACE.
Differential Revision: https://reviews.llvm.org/D29052
llvm-svn: 293422
In this diff, I define a general macro for defining weak functions
with a default implementation: "SANITIZER_INTERFACE_WEAK_DEF()".
This way, we simplify the implementation for different platforms.
For example, we cannot define weak functions on Windows, but we can
use linker pragmas to create an alias to a default implementation.
All of these implementation details are hidden in the new macro.
Also, as I modify the name for exported weak symbols on Windows, I
needed to temporarily disable "dll_host" test for asan, which checks
the list of functions included in asan_win_dll_thunk.
Differential Revision: https://reviews.llvm.org/D28596
llvm-svn: 293419
This reverts r293337, which breaks tests on Windows:
malloc-no-intercept-499eb7.o : error LNK2019: unresolved external symbol _mallinfo referenced in function _main
llvm-svn: 293346
Summary:
In https://bugs.freebsd.org/215125 I was notified that some configure
scripts attempt to test for the Linux-specific `mallinfo` and `mallopt`
functions by compiling and linking small programs which references the
functions, and observing whether that results in errors.
FreeBSD and macOS do not have the `mallinfo` and `mallopt` functions, so
normally these tests would fail, but when sanitizers are enabled, they
incorrectly succeed, because the sanitizers define interceptors for
these functions. This also applies to some other malloc-related
functions, such as `memalign`, `pvalloc` and `cfree`.
Fix this by not intercepting `mallinfo`, `mallopt`, `memalign`,
`pvalloc` and `cfree` for FreeBSD and macOS, in all sanitizers.
Reviewers: emaste, kcc
Subscribers: hans, joerg, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D27654
llvm-svn: 293337
Summary:
-fno-function-sections was added as a default Sanitizer common cflag with
https://reviews.llvm.org/rL200683, the reasoning behind was that things would
break if linked with --gc-sections.
This appears to not be necessary anymore, as tests pass without, including
function-sections-are-bad.cc. There is a large benefit to having
function-sections when dealing with static libraries in terms of size and
dependencies that go away with --gc-sections.
Reviewers: kcc, eugenis
Reviewed By: eugenis
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D29132
llvm-svn: 293220
Currently, os_id of the main thread contains the PID instead of a thread ID. Let's fix this.
Differential Revision: https://reviews.llvm.org/D29106
llvm-svn: 293201
Summary:
Hi Michal,
Would you be able to review this simple fix, please?
Since r291504 compiler-rt uses `llvm-config --cmakedir` to get the path to the LLVM CMake modules.
On Windows this option returns Windows style path with backslashes. CMake treats backslashes as beginning of an escaped character and thus fails to append the path to `CMAKE_MODULE_PATH`.
Reviewers: compnerd, mgorny
Reviewed By: mgorny
Subscribers: compnerd, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D28908
llvm-svn: 293195
Summary:
This patch provides more staging for tail calls in XRay Arm32 . When the logging part of XRay is ready for tail calls, its support in the core part of XRay Arm32 may be as easy as changing the number passed to the handler from 1 to 2.
Coupled patch:
- https://reviews.llvm.org/D28673
Reviewers: dberris, rengolin
Reviewed By: dberris, rengolin
Subscribers: llvm-commits, iid_iunknown, aemerson
Differential Revision: https://reviews.llvm.org/D28674
llvm-svn: 293186
Summary:
This patch provides a trampoline for function tail exit tracing. Still, it's staging because code `1` is passed to the handler function (indicating a normal exit) instead of `2`, which would indicate tail exit. This is so until the logging part of XRay supports tail exits too.
Related: https://reviews.llvm.org/D28947 (LLVM)
Reviewers: dberris, rengolin
Reviewed By: rengolin
Subscribers: aemerson, llvm-commits, iid_iunknown
Differential Revision: https://reviews.llvm.org/D28948
llvm-svn: 293082
Summary:
Adding ARM64 as a supported architecture for Scudo.
The random shuffle is not yet supported for SizeClassAllocator32, which is used
by the AArch64 allocator, so disable the associated test for now.
Reviewers: kcc, alekseyshl, rengolin
Reviewed By: rengolin
Subscribers: aemerson, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28960
llvm-svn: 293068
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
TSan recently got the "ignore_noninstrumented_modules" flag, which disables tracking of read and writes that come from noninstrumented modules (via interceptors). This is a way of suppressing false positives coming from system libraries and other noninstrumented code. This patch turns this on by default on Darwin, where it's supposed to replace the previous solution, "ignore_interceptors_accesses", which disables tracking in *all* interceptors. The new approach should re-enable TSan's ability to find races via interceptors on Darwin.
Differential Revision: https://reviews.llvm.org/D29041
llvm-svn: 292981
pc_array_size and kPcArrayMaxSize appear to be measured in elements, not
bytes, so we shouldn't multiply idx by sizeof(uptr) in this bounds
check. 32-bit Chrome was tripping this assertion because it has 64
million coverage points. I don't think it's worth adding a test that has
that many coverage points.
llvm-svn: 292955
Breaks tests on i686/Linux due to missing clang driver support:
error: unsupported option '-fsanitize=leak' for target 'i386-unknown-linux-gnu'
llvm-svn: 292844
People keep asking LSan to be available on 32 bit targets (e.g. https://github.com/google/sanitizers/issues/403)
despite the fact that false negative ratio might be huge (up to 85%). This happens for big real world applications
that may contain random binary data (e.g. browser), but for smaller apps situation is not so terrible and LSan still might be useful.
This patch adds initial support for x86 Linux (disabled by default), ARM32 is in TODO list.
We used this patch (well, ported to GCC) on our 32 bit mobile emulators and it worked pretty fine
thus I'm posting it here to initiate further discussion.
Differential Revision: https://reviews.llvm.org/D28609
llvm-svn: 292775
This fix a bug, when calling InternalGetProcAddress() for an executable that
doesn't export any symbol. So the table is empty.
If we don't check for this condition, the program fails with Error 0xc0000142.
Also, I add a regression test for Windows.
Differential Revision: https://reviews.llvm.org/D28502
llvm-svn: 292747
Fix the logic used to calculate page boundaries in clear_cache_test to
use correct masks -- e.g. -4096 rather than -4095. The latter gives
incorrect result since:
-4095 -> 0xfffff001
-4096 -> 0xfffff000 (== ~4095)
The issue went unnoticed so far because the array alignment caused
the last bit not to be set. However, on 32-bit x86 no such alignment is
enforced and the wrong page address caused the test to fail.
Furthermore, obtain the page size from the system instead of hardcoding
4096.
Differential Revision: https://reviews.llvm.org/D28849
llvm-svn: 292729
syntax fix
Summary:
Make the asm of aeabi_memset be assembled for thumb1.
Also fix some instructions to conform with the syntax of ARM reference manual.
For example, muls requires the form of "Rd, Rn, Rd" and orrs requires
the form of "Rd, Rm". Clang-as is benign but it may fail other assembler
if not in the exact form.
Reviewers: rengolin, compnerd, kubamracek
Reviewed By: rengolin, compnerd
Subscribers: aemerson, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28971
llvm-svn: 292727
This patch adds some useful macros for dealing with pragma directives on
Windows. Also, I add appropriate documentation for future users.
Differential Revision: https://reviews.llvm.org/D28525
llvm-svn: 292650
Summary:
In an effort to getting rid of dependencies to external libraries, we are
replacing atomic PackedHeader use of std::atomic with Sanitizer's
atomic_uint64_t, which allows us to avoid -latomic.
Reviewers: kcc, phosek, alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28864
llvm-svn: 292630
Running lit tests and unit tests of ASan and TSan on macOS has very bad performance when running with a high number of threads. This is caused by xnu (the macOS kernel), which currently doesn't handle mapping and unmapping of sanitizer shadow regions (reserved VM which are several terabytes large) very well. The situation is so bad that increasing the number of threads actually makes the total testing time larger. The macOS buildbots are affected by this. Note that we can't easily limit the number of sanitizer testing threads without affecting the rest of the tests.
This patch adds a special "group" into lit, and limits the number of concurrently running tests in this group. This helps solve the contention problem, while still allowing other tests to run in full, that means running lit with -j8 will still with 8 threads, and parallelism is only limited in sanitizer tests.
Differential Revision: https://reviews.llvm.org/D28420
llvm-svn: 292549
Summary:
There are cases when thread local quarantine drains almost empty
quarantine batches into the global quarantine. The current approach leaves
them almost empty, which might create a huge memory overhead (each batch
is 4K/8K, depends on bitness).
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28068
llvm-svn: 292525
Summary:
Testing of XRay was occasionally disabled on 32-bit Arm targets (someone assumed that XRay was supported on 64-bit targets only). This patch should fix that problem. Also here the instruction&data cache incoherency problem is fixed, because it may be causing a test to fail.
This patch is one of a series: see also
- https://reviews.llvm.org/D28624
Reviewers: dberris, rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, aemerson, rengolin, dberris, iid_iunknown
Differential Revision: https://reviews.llvm.org/D28623
llvm-svn: 292517
Summary:
Setting -DCOMPILER_RT_TEST_TARGET_TRIPLE=armv6m-none-eabi will enable the build of builtin functions ARMv6m.
Currently, only those asms that support armv6m are added.
TODO:All asm sin ARM_EABI_Sources are ported for thumb1 so Thumb1_EABI_Sources will be deprecated.
Reviewers: rengolin, compnerd
Reviewed By: compnerd
Subscribers: aemerson, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28463
llvm-svn: 292504
Summary:
ARM & AArch64 runtime detection for hardware support of CRC32 has been added
via check of the AT_HWVAL auxiliary vector.
Following Michal's suggestions in D28417, the CRC32 code has been further
changed and looks better now. When compiled with full relro (which is strongly
suggested to benefit from additional hardening), the weak symbol for
computeHardwareCRC32 is read-only and the assembly generated is fairly clean
and straight forward. As suggested, an additional optimization is to skip
the runtime check if SSE 4.2 has been enabled globally, as opposed to only
for scudo_crc32.cpp.
scudo_crc32.h has no purpose anymore and was removed.
Reviewers: alekseyshl, kcc, rengolin, mgorny, phosek
Reviewed By: rengolin, mgorny
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D28574
llvm-svn: 292409
This reverts commit r292211, as it broke the Thumb buldbot with:
clang-5.0: error: the clang compiler does not support '-fxray-instrument
on thumbv7-unknown-linux-gnueabihf'
llvm-svn: 292356
Remove the failing tests for __fixunssfdi() and __fixunsdfdi() that
relied on undefined (and most likely obsolete in terms of compiler-rt
implementation behavior).
Both tests presumed that 0x1.p+64 would be converted to
0xFFFFFFFFFFFFFFFFLL, that is the largest value in uint64 range.
However, the C/C++ standards do not specify the behavior for converting
a floating-point value to an integer of smaller range, and in this case
both libgcc and compiler-rt implementations return 0 instead.
Since the current behavior is correct with regards to standards
and there is no good way of expressing 0xFFFFFFFFFFFFFFFFLL in single-
or double-precision float, I've removed the failing test altogether.
Differential Revision: https://reviews.llvm.org/D28146
llvm-svn: 292257
Making this variable non-static avoids the need for locking to ensure
that the initialization is thread-safe which in turns eliminates the
runtime dependency on libc++abi library (for __cxa_guard_acquire and
__cxa_guard_release) which makes it possible to link scudo against
pure C programs.
Differential Revision: https://reviews.llvm.org/D28757
llvm-svn: 292253
Running lit tests and unit tests of ASan and TSan on macOS has very bad performance when running with a high number of threads. This is caused by xnu (the macOS kernel), which currently doesn't handle mapping and unmapping of sanitizer shadow regions (reserved VM which are several terabytes large) very well. The situation is so bad that increasing the number of threads actually makes the total testing time larger. The macOS buildbots are affected by this. Note that we can't easily limit the number of sanitizer testing threads without affecting the rest of the tests.
This patch adds a special "group" into lit, and limits the number of concurrently running tests in this group. This helps solve the contention problem, while still allowing other tests to run in full, that means running lit with -j8 will still with 8 threads, and parallelism is only limited in sanitizer tests.
Differential Revision: https://reviews.llvm.org/D28420
llvm-svn: 292232
Summary:
Testing of XRay was occasionally disabled on 32-bit Arm targets (someone assumed that XRay was supported on 64-bit targets only). This patch should fix that problem. Also here the instruction&data cache incoherency problem is fixed, because it may be causing a test to fail.
This patch is one of a series: see also
- https://reviews.llvm.org/D28624
Reviewers: dberris, rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, aemerson, rengolin, dberris, iid_iunknown
Differential Revision: https://reviews.llvm.org/D28623
llvm-svn: 292211
Summary:
Bypass quarantine altogether when quarantine size is set ot zero.
Also, relax atomic load/store of quarantine parameters, the
release/acquire semantics is an overkill here.
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D28586
llvm-svn: 291791
Summary:
Repoisoning just the minimal redzones might leave an unpoisoned
gap of the size of the actual redzone minus minimal redzone size.
After ASan activation the actual redzone might be bigger than the minimal
size and ASan allocator assumes that the chunk returned by the common
allocator is either entirely poisoned or entirely not poisoned (it's too
expensive to check the entire chunk or always poison one).
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28577
llvm-svn: 291714
The `-target` impacts the CC for the builtins. HF targets (with either
floating point ABI) always use AAPCS VFP for the builtins unless they
are AEABI builtins, in which case they use AAPCS. Non-HF targets (with
either floating point ABI) always use AAPCS for the builtins and AAPCS
for the AEABI builtins. This introduces the thunks necessary to switch
CC for the floating point operations. This is not currently enabled,
and should be dependent on the target being used to build compiler-rt.
However, as a stop-gap, a define can be added for ASFLAGS to get the
thunks.
llvm-svn: 291677
On Darwin, we currently use 'ignore_interceptors_accesses', which is a heavy-weight solution that simply turns of race detection in all interceptors. This was done to suppress false positives coming from system libraries (non-instrumented code), but it also silences a lot of real races. This patch implements an alternative approach that should allow us to enable interceptors and report races coming from them, but only if they are called directly from instrumented code.
The patch matches the caller PC in each interceptors. For non-instrumented code, we call ThreadIgnoreBegin.
The assumption here is that the number of instrumented modules is low. Most likely there's only one (the instrumented main executable) and all the other modules are system libraries (non-instrumented).
Differential Revision: https://reviews.llvm.org/D28264
llvm-svn: 291631
Summary:
As raised in D28304, enabling SSE 4.2 for the whole Scudo tree leads to the
emission of SSE 4.2 instructions everywhere, while the runtime checks only
applied to the CRC32 computing function.
This patch separates the CRC32 function taking advantage of the hardware into
its own file, and only enabled -msse4.2 for that file, if detected to be
supported by the compiler.
Another consequence of removing SSE4.2 globally is realizing that memcpy were
not being optimized, which turned out to be due to the -fno-builtin in
SANITIZER_COMMON_CFLAGS. So we now explicitely enable builtins for Scudo.
The resulting assembly looks good, with some CALLs are introduced instead of
the CRC32 code being inlined.
Reviewers: kcc, mgorny, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28417
llvm-svn: 291570
Summary: This patch attempts to fix test patching-unpatching.cc . The new code flushes the instruction cache after modifying the program at runtime.
Reviewers: dberris, rengolin, pelikan, rovka
Subscribers: rovka, llvm-commits, iid_iunknown, aemerson
Differential Revision: https://reviews.llvm.org/D27996
llvm-svn: 291568
Revert "ASAN activate/deactive controls thread_local_quarantine_size_kb option."
Revert "Bypass quarantine when quarantine size is set ot zero."
Revert "ASAN activate/deactive controls thread_local_quarantine_size_kb option."
One of these commits broke some of the ARM / AArch64 buildbots:
TEST 'AddressSanitizer-aarch64-linux :: TestCases/Posix/start-deactivated.cc' FAILED
Command Output (stderr):
--
/home/buildslave/buildslave/clang-cmake-aarch64-42vma/llvm/projects/compiler-rt/test/asan/TestCases/Posix/start-deactivated.cc:85:12: error: expected string not found in input
// CHECK: WARNING: AddressSanitizer failed to allocate 0xfff{{.*}} bytes
^
<stdin>:1:1: note: scanning from here
start-deactivated.cc.tmp: /home/buildslave/buildslave/clang-cmake-aarch64-42vma/llvm/projects/compiler-rt/test/asan/TestCases/Posix/start-deactivated.cc:40: void test_malloc_shadow(char *, size_t, bool): Assertion `(char *)__asan_region_is_poisoned(p - 1, sz + 1) == (expect_redzones ? p - 1 : nullptr)' failed.
^
<stdin>:2:1: note: possible intended match here
Error: Aborted (core dumped)
^
llvm-svn: 291560
Summary:
The build system was inconsistent in its naming conventions for
link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS,
for consistency with cmake's LINK_FLAGS property.
This patch should make it easier to search the source code for
uses of link flags, as well as providing the benefit of improved
style and consistency.
Reviewers: compnerd, beanz
Subscribers: kubabrecka, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28506
llvm-svn: 291539
Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config. Fallback to local reconstruction if llvm-config does not
support this option.
llvm-svn: 291504
Summary:
By default, darwin requires a definition for weak interface functions at
link time. Adding the '-U' link flag with each weak function allows these
weak interface functions to be used without definitions, which mirrors
behavior on linux and windows.
Reviewers: compnerd, eugenis
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28203
llvm-svn: 291417
As discussed with Dmitry (https://goo.gl/SA4izd), I would like to introduce a function to be called from a third-party library to flush the shadow memory.
In particular, we ran some experiments with our tool Archer (an OpenMP data race detector based on Tsan, https://github.com/PRUNER/archer) and flushing the memory at the end of an outer parallel region, slightly increase the runtime overhead, but reduce the memory overhead of about 30%. This feature would come very handy in case of very large OpenMP applications that may cause an "out of memory" exception when checked with Tsan.
Reviewed in: https://reviews.llvm.org/D28443
Author: Simone Atzeni (simoatze)
llvm-svn: 291346
Tests need to output everything into a single stream, or FileCheck is sometimes confused (buffering can cause stdout/stderr to be interleaved randomly).
llvm-svn: 291339
Summary:
By default, darwin requires a definition for weak interface functions at
link time. Adding the '-U' link flag with each weak function allows these
weak interface functions to be used without definitions, which mirrors
behavior on linux and windows.
Reviewers: compnerd, eugenis
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28203
llvm-svn: 291314
Summary:
Adds a few default implementations for weak
interface functions on platforms where weak hooks are not supported.
Reviewers: eugenis, samsonov, timurrrr
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28201
llvm-svn: 291313
Summary:
The lsan cmake configuration failed when targeting more
than one architecture, because it would attempt to create multiple
components with the same name. Ensure that only one lsan component
is ever created.
Reviewers: beanz, bogner
Subscribers: dberris, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28151
llvm-svn: 291294
This patch starts passing architecture information about a module to llvm-symbolizer and into text reports. This fixes the longstanding x86_64/x86_64h mismatch issue on Darwin.
Differential Revision: https://reviews.llvm.org/D27390
llvm-svn: 291287
This patch teaches asan_symbolize.py to read an architecture suffix on module names (e.g. ":x86_64") and pass that option to atos and llvm-symbolizer.
Differential Revision: https://reviews.llvm.org/D27378
llvm-svn: 291280
This patch add a new sanitizer flag, print_module_map, which enables printing a module map when the process exits, or after each report (for TSan). The output format is very similar to what Crash Reporter produces on Darwin (e.g. the format of module UUIDs). This enables users to use the existing symbol servers to offline symbolicate and aggregate reports.
Differential Revision: https://reviews.llvm.org/D27400
llvm-svn: 291277
This patch adds tracking which modules are instrumented and which are not. On macOS, instrumented modules link against the ASan/TSan/... dylib, so we can just check if such a load command exists or not.
Differential Revision: https://reviews.llvm.org/D28263
llvm-svn: 291268
Implement the missing __floattitf() and __floatuntitf() functions, to
convert 128-bit (unsigned) integers to quad-precision floating-point
types. This is needed e.g. on AArch64 where 'long double' is
a quad-precision type.
The code is based on the existing code for __floattixf()
and __floatuntixf(), updated to account for different bit field lengths
of quad-precision float. The tests are also copied, with the rounding
tests adjusted for longer significand.
Differential Revision: https://reviews.llvm.org/D27898
llvm-svn: 291259
Summary: This is the compiler-rt side of D28242.
Reviewers: kcc, vitalybuka, pgousseau, gbedwell
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28244
llvm-svn: 291237
Disable the code appending -msse4.2 flag implicitly when the compiler
supports it. The compiler support for this flags do not indicate that
the underlying CPU will support SSE4.2, and passing it may result in
SSE4.2 code being emitted *implicitly*.
If the target platform supports SSE4.2 appropriately, the relevant bits
should be already enabled via -march= or equivalent. In this case
passing -msse4.2 is redundant.
If a runtime detection is desired (which seems to be a case with SCUDO),
then (as gcc manpage points out) the specific SSE4.2 needs to be
isolated into a separate file, the -msse4.2 flag can be forced only
for that file and the function defined in that file can only be called
when the CPU is determined to support SSE4.2.
This fixes SIGILL on SCUDO when it is compiled using gcc-5.4.
Differential Revision: https://reviews.llvm.org/D28304
llvm-svn: 291217
Summary:
Debug builds can have larger distance between stack trace and PC on that stack.
If we assume that PC is always correct we can snap it to the nearest trace.
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D28342
llvm-svn: 291173
The reason they should have failed: absent sancov.
In this test (vs the trace_pc_guard test) sancov is not
yet called (not implemented).
llvm-svn: 291080
a warning that 'gtest-all.cc' directly triggers in the newer 1.8.0
version.
This should fix a warning in folks' build and bring a couple of -Werror
bots back to life.
llvm-svn: 291070
Summary:
At this point SANCOV_OPTIONS are not functional but it is our intent
to move here sanitizer coverage flags from various sanitizers _OPTIONS.
Reviewers: kcc
Subscribers: kubabrecka, mgorny
Differential Revision: https://reviews.llvm.org/D28311
llvm-svn: 291068
Summary:
A previous fix used __assume(0), but not all compilers know that control will
not pass that. This patch uses a macro which works in more compilers.
Reviewers: rnk
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D28268
llvm-svn: 291042
Summary:
We put empty object files in archives, which causes MSVC's linker to
complain about these objects not defining any previously undefined
symbols. Since we do it on purpose, this only creates noise during
the build process. This patch causes us to suppress the warnings.
Reviewers: rnk, samsonov
Subscribers: dberris, mgorny
Differential Revision: https://reviews.llvm.org/D28262
llvm-svn: 291011
Summary:
If you decide to recompile parts of your Linux distro with XRay, it may
be useful to know which trace belongs to which binary. While there, get
rid of the incorrect strncat() usage; it always returns a pointer to the
start which makes that if() always true. Replace with snprintf which is
bounded so that enough from both strings fits nicely.
Reviewers: dberris
Subscribers: danalbert, srhines, kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D27912
llvm-svn: 290861
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 290852
Summary:
Make kLargeMalloc big enough to be handled by secondary allocator
and small enough to fit into quarantine for all configurations.
It become too big to fit into quarantine on Android after D27873.
Reviewers: eugenis
Patch by Alex Shlyapnikov.
Subscribers: danalbert, llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D28142
llvm-svn: 290689
Summary:
Reduce RSS size treshold in the unit test to accomodate for the smaller
ASAN quarantine size on Android (see D27873).
Reviewers: eugenis
Patch by Alex Shlyapnikov.
Subscribers: danalbert, kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28132
llvm-svn: 290643
Use some new substitutions to avoid duplicating the tests for just
dropped flags. -fPIC/-fPIE/-fpic/-fpie do not make sense on Windows as
they can cause ELF-style PIC. Substitute away the flag on Windows.
This should repair the windows buildbots.
llvm-svn: 290571
Updated test according to commit 290539:
According to extended asm syntax, a case where the clobber list includes a variable from the inputs or outputs should be an error - conflict.
for example:
const long double a = 0.0;
int main()
{
char b;
double t1 = a;
__asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)");
return 0;
}
This should conflict with the output - t1 which is st, and st which is st aswell.
The patch fixes it.
Commit on behald of Ziv Izhar.
Differential Revision: https://reviews.llvm.org/D15075
llvm-svn: 290540
This allows compiler-rt to be built on older macOS SDKs, where there symbols are not defined.
Patch by Jeremy Huddleston Sequoia <jeremyhu@apple.com>.
llvm-svn: 290521
Summary: This patch attempts to fix test patching-unpatching.cc . The new code flushes the instruction cache after modifying the program at runtime.
Reviewers: dberris, rengolin
Subscribers: llvm-commits, iid_iunknown, aemerson
Differential Revision: https://reviews.llvm.org/D27996
llvm-svn: 290452
Summary: The macro was introduced with D26929, use it in Scudo as well.
Reviewers: kcc, alekseyshl, kubabrecka
Subscribers: llvm-commits, danalbert, srhines, mgorny
Differential Revision: https://reviews.llvm.org/D28066
llvm-svn: 290439
Fix missing "int_lib.h" includes in ARM negdf2vfp and subdf3vfp tests.
Additionally, extend the __arm__ guard to cover the builtin definition
in the former. This is mostly intended to prevent build failures
and allow those tests to be properly skipped on other targets.
Differential Revision: https://reviews.llvm.org/D28078
llvm-svn: 290422
Summary: We setup these interceptors twice which hangs test on windows.
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D28070
llvm-svn: 290393
Summary: Make thread local quarantine size an option so it can be turned off to save memory.
Reviewers: eugenis
Patch by Alex Shlyapnikov.
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28027
llvm-svn: 290373
Summary:
Warm up ASAN caches in ThreadedQuarantineTest to get more predictable
incremental heap memory usage measurements.
Reviewers: eugenis
Patch by Alex Shlyapnikov.
Subscribers: aemerson, kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28061
llvm-svn: 290371
Summary: This patch attempts to fix test patching-unpatching.cc . The new code flushes the instruction cache after modifying the program at runtime.
Reviewers: dberris, rengolin
Subscribers: llvm-commits, iid_iunknown, aemerson
Differential Revision: https://reviews.llvm.org/D27996
llvm-svn: 290354
Summary:
Experiments show that on Android the current values result in too much
of the memory consumption for all quarantined chunks.
Reviewers: kcc, eugenis
Subscribers: mgorny, danalbert, srhines, llvm-commits, kubabrecka
Patch by Aleksey Shlyapnikov.
Differential Revision: https://reviews.llvm.org/D27873
llvm-svn: 290218
Summary:
With the previous modifications, the code works on ARM32. The random shuffle
test is unsupported on 32-bit platforms for the moment and being marked as
such. There is no hardware support for the checksum computation yet, this will
come at a later point.
Reviewers: kcc, alekseyshl
Subscribers: llvm-commits, aemerson, rengolin, mgorny
Differential Revision: https://reviews.llvm.org/D27957
llvm-svn: 290201
Summary:
After rL289878/rL289881, the build on FreeBSD is broken, because
sanitizer_platform_limits_posix.cc attempts to include <utmp.h> and use
`struct utmp`, neither of which are supported anymore on FreeBSD.
Fix this by adding `&& !SANITIZER_FREEBSD` in a few places, and stop
intercepting utmp functions altogether for FreeBSD.
Reviewers: kubabrecka, emaste, eugenis, ed
Subscribers: ed, llvm-commits
Differential Revision: https://reviews.llvm.org/D27902
llvm-svn: 290167
In ASan, we have __asan_locate_address and __asan_get_alloc_stack, which is used in LLDB/Xcode to show the allocation backtrace for a heap memory object. This patch implements the same for TSan.
Differential Revision: https://reviews.llvm.org/D27656
llvm-svn: 290119
Missed a couple of files:
- Using #pragma once
- Missing top-matter for headers
- Missing an include for <cstdint>
Follow-up on D25360.
llvm-svn: 290079
Summary:
Getting rid of the distance number altogether because:
- a person knowledgeable enough to know what the message means will also
know how to do hexadecimal math (with the help of a calculator)
- numbers outside INT_MIN - INT_MAX are hard to comprehend anyway
This unbreaks the case when you dynamically link a library with XRay and
it exits pre-main() with a not very informative static string.
Author: pelikan
Reviewers: dberris
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D27894
llvm-svn: 290074
projects/compiler-rt/lib/xray/xray_trampoline_x86_64.S:33:7: error: unexpected token in '.endm' directive
.endm SAVE_REGISTERS
^
projects/compiler-rt/lib/xray/xray_trampoline_x86_64.S:52:7: error: unexpected token in '.endm' directive
.endm RESTORE_REGISTERS
^
Remove the trailing name on the `.endm` which does not take the name of the
macro. This should bring the compiler-rt build bot back into working state.
llvm-svn: 289852
Summary:
With the recent changes to the Secondary, we use less bits for UnusedBytes,
which allows us in return to increase the bits used for Offset. That means
that we can use a Primary SizeClassMap allowing for a larger maximum size.
Reviewers: kcc, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27816
llvm-svn: 289838
We already have an interceptor for __shared_weak_count::__release_shared, this patch handles __shared_count::__release_shared in the same way. This should get rid of TSan false positives when using std::future.
Differential Revision: https://reviews.llvm.org/D27797
llvm-svn: 289831
Summary:
The layout of all registers saved on stack shouldn't deviate and will be reused in future trampolines as well.
While there, fix whitespace and clarify comments.
Author: mpel
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27799
llvm-svn: 289789
Objects may move during the garbage collection, and JVM needs
to notify ThreadAnalyzer about that. The new function
__tsan_java_find eliminates the need to maintain these
objects both in ThreadAnalyzer and JVM.
Author: Alexander Smundak (asmundak)
Reviewed in https://reviews.llvm.org/D27720
llvm-svn: 289682
Summary:
Now that we are not rounding up the sizes passed to the secondary allocator,
the memalign test could run out of aligned addresses to return for larger
alignments. We now reduce the size of the quarantine for that test, and
allocate less chunks for the larger alignments.
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27760
llvm-svn: 289665
Summary:
I atually had an integer overflow on 32-bit with D27428 that didn't reproduce
locally, as the test servers would manage allocate addresses in the 0xffffxxxx
range, which led to some issues when rounding addresses.
At this point, I feel that Scudo could benefit from having its own combined
allocator, as we don't get any benefit from the current one, but have to work
around some hurdles (alignment checks, rounding up that is no longer needed,
extraneous code).
Reviewers: kcc, alekseyshl
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D27681
llvm-svn: 289572
This doesn't work at all on big-endian systems, even just reading in the
magic bytes in the binary .sancov file header gets byte order wrong.
llvm-svn: 289539
fatal error: error in backend: Global variable '__sancov_gen_' has an
invalid section specifier '__sancov_guards': mach-o section specifier
requires a segment and section separated by a comma.
llvm-svn: 289507
Summary:
This should improve the error messages generated providing a bit more
information when the failures are printed out. One example of a
contrived error looks like:
```
Expected: (Buffers.getBuffer(Buf)) != (std::error_code()), actual:
system:0 vs system:0
```
Because we're using error codes, the default printing gets us more
useful information in case of failure.
This is a follow-up on D26232.
Reviewers: rSerge
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27495
llvm-svn: 289501
This is used when building builtins for multiple targets as part
of LLVM runtimes.
Differential Revision: https://reviews.llvm.org/D26653
llvm-svn: 289489
This target doesn't currently do anything, but it is required by
the runtimes build.
Differential Revision: https://reviews.llvm.org/D27640
llvm-svn: 289420
In certain OS versions, it was possible that libmalloc replaced the sanitizer zone from being the default zone (i.e. being in malloc_zones[0]). This patch introduces a failsafe that makes sure we always stay the default zone. No testcase for this, because this doesn't reproduce under normal circumstances.
Differential Revision: https://reviews.llvm.org/D27083
llvm-svn: 289376
We currently have a interceptor for malloc_create_zone, which returns a new zone that redirects all the zone requests to our sanitizer zone. However, calling malloc_destroy_zone on that zone will cause libmalloc to print out some warning messages, because the zone is not registered in the list of zones. This patch handles this and adds a testcase for that.
Differential Revision: https://reviews.llvm.org/D27083
llvm-svn: 289375
Summary: I see crashes on this check when some reports are being generated.
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D27574
llvm-svn: 289145
Summary:
The combined allocator rounds up the requested size with regard to the
alignment, which makes sense when being serviced by the primary as it comes
with alignment guarantees, but not with the secondary. For the rare case of
large alignments, it wastes memory, and entices unnecessarily large fields for
the Scudo header. With this patch, we pass the non-alignement-rounded-up size
to the secondary, and adapt the Scudo code for this change.
Reviewers: alekseyshl, kcc
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D27428
llvm-svn: 289088
Summary: For platforms which support slow unwinder only, we restrict the store context size to 1, basically only storing the current pc. We do this because the slow unwinder which is based on libunwind is not async signal safe and causes random freezes in forking applications as well as in signal handlers.
Reviewed by eugenis.
Differential: D23107
llvm-svn: 289027
Summary:
The test `XRay-aarch64-linux::patching-unpatching.cc` sometimes passes, sometimes fails on buildbots.
This patch disables test `patching-unpatching.cc` for AArch64 targets.
Reviewers: rengolin, dberris
Subscribers: llvm-commits, iid_iunknown, aemerson
Differential Revision: https://reviews.llvm.org/D27528
llvm-svn: 288988
Summary:
For idivsi3, convert the Thumb2 only instruction to thumb1.
For aeabi_idivmod, using __divsi3.
Reviewers: rengolin, compnerd
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27472
llvm-svn: 288960
Summary: Since CLZ is not available for Thumb1, we use __ARM_ARCH_ISA_THUMB != 1 as one of the conditions.
Reviewers: rnk, compnerd, rengolin
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27530
llvm-svn: 288954
Summary: Old bash release (3.2) on SLES11 chokes on new redirection shortcut.
Patch by Brian Cain.
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D27443
llvm-svn: 288854
As constructed before this patch, in case we run into case where we
don't actually build the XRay library, we really ought to not be adding
the unit test runs. This should fix the bootstrap build failures.
This is a follow-up further to D26232.
llvm-svn: 288788
The bootstrap buildbot complains about not being able to find the
unittests for XRay, when the conditionals to include or not include
tests and unit tests don't match.
This is a follow-up to D26232.
llvm-svn: 288786
Before this change we would add the unit tests potentially even if we
don't actually include the unit tests.
This is a follow-up on D26232.
llvm-svn: 288785
Before this, the change committed in D26232 might have an uninitialised
std::atomic<bool> that may or may not have a valid state. On aarch64
this breaks consistently, while it doesn't manifest as a problem in
x86_64.
This is an attempt to un-break this in aarch64.
llvm-svn: 288776
This implements a simple buffer queue to manage a pre-allocated queue of
fixed-sized buffers to hold XRay records. We need this to support
Flight Data Recorder (FDR) mode. We also implement this as a sub-library
first to allow for development before actually using it in an
implementation.
Some important properties of the buffer queue:
- Thread-safe enqueueing/dequeueing of fixed-size buffers.
- Pre-allocation of buffers at construction.
This is a re-roll of the previous attempt to submit, because it caused
failures in arm and aarch64.
Reviewers: majnemer, echristo, rSerge
Subscribers: tberghammer, danalbert, srhines, modocache, mehdi_amini, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26232
llvm-svn: 288775
Summary: Currently test XRay-aarch64-linux::patching-unpatching.cc sometimes passes, sometimes fails. This is an attempt to fix it by handling better the situations when both `__arm__` and `__aarch64__` are defined.
Reviewers: dberris, rengolin
Subscribers: llvm-commits, iid_iunknown, aemerson, rengolin, dberris
Differential Revision: https://reviews.llvm.org/D27421
llvm-svn: 288729
Summary: The function computes full module name and coverts pc into offset.
Reviewers: kcc
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D26820
llvm-svn: 288711
Summary:
The current uidiv supports archs without clz. However, the asm is for thumb2/arm.
For uidivmod, the existing code calls the C version of uidivmodsi4, which then calls uidiv. The extra push/pop/bl makes it less efficient.
Reviewers: jmolloy, jroelofs, joerg, compnerd, rengolin
Subscribers: llvm-commits, aemerson
Differential Revision: https://reviews.llvm.org/D27309
llvm-svn: 288710
Since we’re adding an entry into COMPILER_RT_SUPPORTED_ARCH for all architectures of all Darwin platforms, COMPILER_RT_SUPPORTED_ARCH often ends up having duplicate items. Let’s remove them.
Differential Revision: https://reviews.llvm.org/D25996
llvm-svn: 288681
TSan runtime shouldn't contain memset, so internal_memset is used
instead and syntax that emits memset is avoided.
This doesn't fail in-tree due to TSan being build with -03, but it fails
when TSan is built with -O0, and is (I think) a true positive.
Patch by Sam McCall, review: https://reviews.llvm.org/D27407
llvm-svn: 288672
On macOS, we often symbolicate using atos (when llvm-symbolizer is not found). The current way we invoke atos involves creating a pseudo-terminal to make sure atos doesn't buffer its output. This however also makes atos think that it's stdin is interactive and in some error situations it will ask the user to enter some input instead of just printing out an error message. For example, when Developer Mode isn't enabled on a machine, atos cannot examine processes, and it will ask the user to enter an administrator's password, which will make the sanitized process get stuck. This patch only connects the pseudo-terminal to the stdout of atos, and uses a regular pipe as its stdin.
Differential Revision: https://reviews.llvm.org/D27239
llvm-svn: 288624
When we enumerate loaded modules, we only track the module name and base address, which then has several problems on macOS. Dylibs and executables often have several architecture slices and not storing which architecture/UUID is actually loaded creates problems with symbolication: A file path + offset isn't enough to correctly symbolicate, since the offset can be valid in multiple slices. This is especially common for Haswell+ X86_64 machines, where x86_64h slices are preferred, but if one is not available, a regular x86_64 is loaded instead. But the same issue exists for i386 vs. x86_64 as well.
This patch adds tracking of arch and UUID for each LoadedModule. At this point, this information isn't used in reports, but this is the first step. The goal is to correctly identify which slice is loaded in symbolication, and also to output this information in reports so that we can tell which exact slices were loaded in post-mortem analysis.
Differential Revision: https://reviews.llvm.org/D26632
llvm-svn: 288537
Summary:
Unfortunately, there is no way to emit an llvm masked load/store in
clang without optimizations, and AVX enabled. Unsure how we should go
about making sure this test only runs if it's possible to execute AVX
code.
Reviewers: kcc, RKSimon, pgousseau
Subscribers: kubabrecka, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D26506
llvm-svn: 288504
The previous change for enabling MinGW did not preserve the Win32 check and
added the EABI specific routines to a Windows build which does not use the EABI
routines. Correct the conditional check for that.
llvm-svn: 288422
Summary:
The current code was sometimes attempting to release huge chunks of
memory due to undesired RoundUp/RoundDown interaction when the requested
range is fully contained within one memory page.
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits
Patch by Aleksey Shlyapnikov.
Differential Revision: https://reviews.llvm.org/D27228
llvm-svn: 288271
Summary:
This update introduces i386 support for the Scudo Hardened Allocator, and
offers software alternatives for functions that used to require hardware
specific instruction sets. This should make porting to new architectures
easier.
Among the changes:
- The chunk header has been changed to accomodate the size limitations
encountered on 32-bit architectures. We now fit everything in 64-bit. This
was achieved by storing the amount of unused bytes in an allocation rather
than the size itself, as one can be deduced from the other with the help
of the GetActuallyAllocatedSize function. As it turns out, this header can
be used for both 64 and 32 bit, and as such we dropped the requirement for
the 128-bit compare and exchange instruction support (cmpxchg16b).
- Add 32-bit support for the checksum and the PRNG functions: if the SSE 4.2
instruction set is supported, use the 32-bit CRC32 instruction, and in the
XorShift128, use a 32-bit based state instead of 64-bit.
- Add software support for CRC32: if SSE 4.2 is not supported, fallback on a
software implementation.
- Modify tests that were not 32-bit compliant, and expand them to cover more
allocation and alignment sizes. The random shuffle test has been deactivated
for linux-i386 & linux-i686 as the 32-bit sanitizer allocator doesn't
currently randomize chunks.
Reviewers: alekseyshl, kcc
Subscribers: filcab, llvm-commits, tberghammer, danalbert, srhines, mgorny, modocache
Differential Revision: https://reviews.llvm.org/D26358
llvm-svn: 288255
__sanitizer_contiguous_container_find_bad_address computes three regions of a
container to check for poisoning: begin, middle, end. The issue is that in current
design the first region can be significantly larger than kMaxRangeToCheck.
Proposed patch fixes a typo to calculate the first region properly.
Patch by Ivan Baravy.
Differential Revision: https://reviews.llvm.org/D27061
llvm-svn: 288234
The Clang driver on macOS decides the deployment target based on various things, like your host OS version, the SDK version and some environment variables, which makes lit tests pass or fail based on your environment. Let's make sure we run all lit tests with `-mmacosx-version-min=${SANITIZER_MIN_OSX_VERSION}` (10.9 unless overriden).
Differential Revision: https://reviews.llvm.org/D26929
llvm-svn: 288186
Summary:
Unfortunately, there is no way to emit an llvm masked load/store in
clang without optimizations, and AVX enabled. Unsure how we should go
about making sure this test only runs if it's possible to execute AVX
code.
Reviewers: kcc, RKSimon, pgousseau
Subscribers: kubabrecka, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D26506
llvm-svn: 288162
Summary: In profile data paths, we replace "%h" with the hostname of the machine the program is running on. On Windows, we used gethostname() to obtain the hostname. This requires linking with ws2_32. With this change, we instead get the hostname from GetComputerNameExW(), which does not require ws2_32.
Reviewers: rnk, vsk, amccarth
Subscribers: zturner, ruiu, hans
Differential Revision: https://reviews.llvm.org/D27178
llvm-svn: 288146
This fixes an incorrect standard usage of GNU99 when the compiler check was for
the ISO standard C99. Furthermore, bump the dependency up to C11. The
motivation for this change is ARM EHABI compatibility with clang 3.8. We rely
on a type definition redefinition which causes an error with -Werror builds.
This is problematic for FreeBSD builds. Switching to C11 allows the
compatibility without the unnecessary pedantic warning. The alternative would
be to clutter the support header with a `pragma clang diagnostic ignore`. GCC
4.8+ and the supported clang revisions along with MSVC support enough of C11 to
allow building the builtins in C11 mode. No functional change intended.
llvm-svn: 288099
Summary:
In order to avoid starting a separate thread to return unused memory to
the system (the thread interferes with process startup on Android,
Zygota waits for all threads to exit before fork, but this thread never
exits), try to return it right after free.
Reviewers: eugenis
Subscribers: cryptoad, filcab, danalbert, kubabrecka, llvm-commits
Patch by Aleksey Shlyapnikov.
Differential Revision: https://reviews.llvm.org/D27003
llvm-svn: 288091
See D19555 for rationale. As it turns out, this treatment is also necessary
for scanf/printf.
Differential Revision: https://reviews.llvm.org/D27118
llvm-svn: 288064
The lit expansion of "%deflake " (notice the space after) expands in a way that the space is removed, this fixes that.
Differential Revision: https://reviews.llvm.org/D27139
llvm-svn: 287989
Handling SIGILL on Darwin works fine, so let's just make this feature work and re-enable the ill.cc testcase.
Differential Revision: https://reviews.llvm.org/D27141
llvm-svn: 287959
This patch prints out all CPU registers after a SIGSEGV. These are available in the signal handler context. Only implemented for Darwin. Can be turned off with the dump_registers flag.
Differential Revision: https://reviews.llvm.org/D11365
llvm-svn: 287957
Summary:
This implements a simple buffer queue to manage a pre-allocated queue of
fixed-sized buffers to hold XRay records. We need this to support
Flight Data Recorder (FDR) mode. We also implement this as a sub-library
first to allow for development before actually using it in an
implementation.
Some important properties of the buffer queue:
- Thread-safe enqueueing/dequeueing of fixed-size buffers.
- Pre-allocation of buffers at construction.
Reviewers: majnemer, rSerge, echristo
Subscribers: mehdi_amini, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26232
llvm-svn: 287910
GCD queues can be suspended and resumed with dispatch_suspend and dispatch_resume. We need to add synchronization between the call to dispatch_resume and any subsequent executions of blocks in the queue that was resumed. We already have an Acquire(q) before the block executes, so this patch just adds the Release(q) in an interceptor of dispatch_resume.
Differential Revision: https://reviews.llvm.org/D27112
llvm-svn: 287902
The MSVC incremental linker pads every global out to 256 bytes in case
it changes size after an incremental link. So, skip over null entries in
the DSO-wide asan globals array. This only works if the global padding
size is divisible by the size of the asan global object, so add some
defensive CHECKs.
llvm-svn: 287780
This goes through all the calls to `Report(...)` to make sure that each
one would have a newline at the end of the message for readability.
llvm-svn: 287736
/proc/self/maps can't be read atomically, this leads to episodic
crashes in libignore as it thinks that a module is loaded twice.
See the new test for an example.
dl_iterate_phdr does not have this problem.
Switch libignore to dl_iterate_phdr.
llvm-svn: 287632
The ODR detection in initialization-bug.cc now works on Darwin (due to the recently enabled "live globals" on-by-default), but only if the deployment target is 10.11 or higher. Let's adjust the testcases.
Differential Revision: https://reviews.llvm.org/D26927
llvm-svn: 287581
Summary:
Turns out that in the case of -fsanitize=null and a virtual call,
the type check was generated *after* reading from vtable, which
causes a non-interpretable segfault. The check has been moved up
in https://reviews.llvm.org/D26559 and this CL adds a test for this case.
Reviewers: pcc
Subscribers: cfe-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D26560
llvm-svn: 287578
When building with clang/LLVM in MSVC mode, the msvcrt libraries contain
these functions.
When building in a mingw environment, we need to provide them somehow,
e.g. via compiler-rt.
The aeabi divmod functions work in the same way as the corresponding
__rt_*div* functions for windows, but their parameters are swapped.
The functions for converting float to integer and vice versa are the
same as their aeabi equivalents, only with different function names.
Differential Revision: https://reviews.llvm.org/D26183
llvm-svn: 287465
We're seeying these errors with GCC and Clang on different systems, while
some other identical OSs on different boards fail. Like many other ASAN
tests, there seem to be no easy way to investigate this other than someone
familiar with the sanitizer code and the ARM libraries.
At least, for now, we'll silence the bots. I'll create a bugzilla entry.
llvm-svn: 287464
Summary: The new name better corresponds to its logic.
Reviewers: kcc
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D26821
llvm-svn: 287377
When the C unwinding personality was corrected to match the ARM EHABI
specification, the unwind header in clang was updated with necessary
declarations. However, when building with an older compiler, we would not have
the necessary declarations. This would result in a build failure. Provide a
supplementary header to ensure that the necessary declarations are present for
the build of the C unwinding personality.
Note that this is NOT an ABI break. It merely is a compile time failure due to
the constants not being present. The constants here are reproduced
equivalently. This header should permit building with clang[<3.9] as well as
gcc.
Addresses PR31035!
llvm-svn: 287359
Summary:
The expectation is that new instrumented code will add global variable
metadata to the .ASAN$GL section, and we will use this new code to
iterate over it.
This technique seems to break when using incremental linking, which
seems to align every global to a 256 byte boundary. Presumably this is
so that it can incrementally cope with global changing size. Clang
already passes -incremental:no as a linker flag when you invoke it to do
the link step.
The two tests added for this feature will fail until the LLVM
instrumentation change in D26770 lands, so they are marked XFAIL for
now.
Reviewers: pcc, kcc, mehdi_amini, kubabrecka
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D26771
llvm-svn: 287246
Use the __SSE2__ to determine whether SSE2 is enabled in the ASAN tests
rather than relying on either of the __i686__ and __x86_64__. The former
is only set with explicit -march=i686, and therefore misses most of
the x86 CPUs that support SSE2. __SSE2__ is in turn defined if
the current settings (-march, -msse2) indicate that SSE2 is supported
which should be more reliable.
Differential Revision: https://reviews.llvm.org/D26763
llvm-svn: 287245
Include xray_defs.h in xray_arm.cc (seems to be the only one that doesn't
include it).
Buildbot errors:
[...]/compiler-rt/lib/xray/xray_arm.cc:31:58: error: expected initializer before 'XRAY_NEVER_INSTRUMENT'
inline static uint32_t getMovwMask(const uint32_t Value) XRAY_NEVER_INSTRUMENT {
llvm-svn: 287089
Summary:
Adds a CMake check for whether the compiler used to build the XRay
library supports XRay-instrumentation. If the compiler we're using does
support the `-fxray-instrument` flag (i.e. recently-built Clang), we
define the XRAY_NEVER_INSTRUMENT macro that then makes sure that the
XRay runtime functions never get XRay-instrumented.
This prevents potential weirdness involved with building the XRay
library with a Clang that supports XRay-instrumentation, and is
attempting to XRay-instrument the build of compiler-rt.
Reviewers: majnemer, rSerge, echristo
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D26597
llvm-svn: 287068
Users often have their own unhandled exception filters installed. ASan
already goes to great lengths to install its own filter, but our core
wars with Chrome crashpad have escalated to the point that its time to
declare a truce. By exposing this hook, they can call us directly when
they want ASan crash reporting without worrying about who initializes
when.
llvm-svn: 287040
On Darwin, we're running the TSan unit tests without interceptors. To make sure TSan observes all the pthread events (thread creating, thread join, condvar signal, etc.) in tsan_posix.cc, we should call the pthread interceptors directly, as we already do in tsan_test_util_posix.cc. This fixes some flaky failures on Darwin bots.
Differential Revision: https://reviews.llvm.org/D26639
llvm-svn: 287026
Summary:
In a 32-bit address space, PC-relative jump targets are wrapped, so a
direct branch at 0x90000001 can reach address 0x10000000 with a
displacement of 0x7FFFFFFFF. This can happen in applications, such as
Chrome, that are linked with /LARGEADDRESSAWARE.
Reviewers: etienneb
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26650
llvm-svn: 286997
This adds support for TSan C++ exception handling, where we need to add extra calls to __tsan_func_exit when a function is exitted via exception mechanisms. Otherwise the shadow stack gets corrupted (leaked). This patch moves and enhances the existing implementation of EscapeEnumerator that finds all possible function exit points, and adds extra EH cleanup blocks where needed.
Differential Revision: https://reviews.llvm.org/D26177
llvm-svn: 286894
It's not a good idea to build the sanitizers with e.g. -DCMAKE_OSX_DEPLOYMENT_TARGET=10.12, because some deprecated functions that we intercept will cause build errors. Let's limit the allowed deployment targets to 10.9 (which is the default anyway), and warn when it's set above.
Differential Revision: https://reviews.llvm.org/D26557
llvm-svn: 286859
Summary:
ASan needs to initialize before ucrtbase.dll so that it can intercept
all of its heap allocations. New versions of dbghelp.dll depend on
ucrtbase.dll, which means both of those DLLs will initialize before the
dynamic ASan runtime. By lazily loading dbghelp.dll with LoadLibrary, we
avoid the issue.
Eventually, I would like to remove our dbghelp.dll dependency in favor
of always using llvm-symbolizer.exe, but this seems like an acceptable
interim solution.
Fixes PR30903
Reviewers: etienneb
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26473
llvm-svn: 286848
This patch replaces fprintf with print_address function in LSAN
tests. This is necessary because of different printing of pointers
in fprintf and sanitizer's print function.
Differential Revision: https://reviews.llvm.org/D26084.
llvm-svn: 286816
Summary:
In non-strict mode we will check memory access for both strings from beginning
to either:
1. 0-char
2. size
3. different chars
In strict mode we will check from beginning to either:
1. 0-char
2. size
Previously in strict mode we always checked up to the 0-char.
Reviewers: kcc, eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D26574
llvm-svn: 286708
Summary: Unit tests for the new clang flags.
Reviewers: eugenis, dvyukov
Subscribers: kubabrecka, llvm-commits
Patch by Alex Shlyapnikov.
Differential Revision: https://reviews.llvm.org/D26462
llvm-svn: 286670
This patch is needed to implement the function attribute that disable TSan checking at run time.
Differential Revision: https://reviews.llvm.org/D25859
llvm-svn: 286658
Changed the kernel sigaction structure in test syscalls_sigaction.cc for MIPS according to the structure defined in kernel.
Reviewed by eugenis.
Differential: https://reviews.llvm.org/D25814
llvm-svn: 286583
Now that we use TerminateProcess, the debugger doesn't stop on program
exit. Add this breakpoint so that the debugger stops after asan reports
an error and is prepared to exit the program.
llvm-svn: 286501
ExitProcess still runs some code which can lead to ASan interceptors
running after CHECK failure. This can lead to deadlock if it CHECK fails
again. Avoid that mess by really exiting immediately.
llvm-svn: 286395
I'm not sure why is it there, but it is breaking tests on Android N
because of unexpected linker output about an empty LD_LIBRARY_PATH
entry.
llvm-svn: 286321
Summary:
User applications may register hooks in the .CRT$XL* callback list,
which is called very early by the loader. This is very common in
Chromium:
https://cs.chromium.org/search/?q=CRT.XL&sq=package:chromium&type=cs
This has flown under the radar for a long time because the loader
appears to catch exceptions originating from these callbacks. It's a
real problem when you're debugging an asan application, though, since it
makes the program crash early.
The solution is to add our own callback to this list, and sort it very
early in the list like we do elsewhere. Also add a test with such an
instrumented callback, and test that it gets called with asan.
Reviewers: etienneb
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D26404
llvm-svn: 286290
Atomic stores terminate release sequences on the atomic variable,
and must use ReleaseStore primitive instead of Release.
This was broken in r192355 during a refactoring.
Restore correct behavior and add a test.
llvm-svn: 286211
asan_device_setup script is using LD_PRELOAD to inject the ASan
runtime library into the Zygote process. This breaks when the Zygote
or any of its descendants spawn a process with different bitness due
to the fact that the ASan-RT library name includes the target
architecture.
The fix is to preload the library through a symlink which has the
same name in lib and lib64.
llvm-svn: 286188
Although rare, atomic accesses to floating-point types seem to be valid, i.e. `%a = load atomic float ...`. The TSan instrumentation pass however tries to emit inttoptr, which is incorrect, we should use a bitcast here. Anyway, IRBuilder already has a convenient helper function for this.
Differential Revision: https://reviews.llvm.org/D26266
llvm-svn: 286136
Only tests using %clang_cl_asan were using the dynamic CRT before this.
The unit tests and lit tests using %clangxx_asan were using the static
CRT. Many cross-platform tests fail with the dynamic CRT, so I had to
add win32-(static|dynamic)-asan lit features.
Also deletes some redundant tests in TestCases/Windows that started
failing with this switch.
llvm-svn: 285821
Summary:
We define a new trampoline that's a hybrid between the exit and entry
trampolines with the following properties:
- Saves all of the callee-saved registers according to the x86_64
calling conventions.
- Indicate to the log handler function being called that this is a
function exit event.
This fixes a bug that is a result of not saving enough of the register
states, and that the log handler is clobbering registers that would be
used by the function being tail-exited into manifesting as runtime
errors.
Reviewers: rSerge, echristo, majnemer
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D26020
llvm-svn: 285787
Apparently, the std_shared_ptr.cc testcase works fine on Darwin, even without the instrumented libcxx. Let's enable it.
Differential Revision: https://reviews.llvm.org/D26162
llvm-svn: 285634
TSan’s memory usage profiling currently doesn’t work on Darwin. This patch implements measuring the amount of resident and dirty memory for each memory region. I also removed the GetShadowMemoryConsumption function, which seems to be unused.
Differential Revision: https://reviews.llvm.org/D25973
llvm-svn: 285630
On Darwin, simple C null-terminated constant strings normally end up in the __TEXT,__cstring section of the resulting Mach-O binary. When instrumented with ASan, these strings are transformed in a way that they cannot be in __cstring (the linker unifies the content of this section and strips extra NUL bytes, which would break instrumentation), and are put into a generic __const section. This breaks some of the tools that we have: Some tools need to scan all C null-terminated strings in Mach-O binaries, and scanning all the contents of __const has a large performance penalty. This patch instead introduces a special section, __asan_cstring which will now hold the instrumented null-terminated strings.
Differential Revision: https://reviews.llvm.org/D25026
llvm-svn: 285620
GCD (libdispatch) has a concept of “target queues”: Each queue has either an implicit or explicit target queue, where the task is handed over to when it’s time to execute it. For example, a concurrent queue can have a serial target queue (effectively making the first queue serial), or multiple queues can have the same serial target queue (which means tasks in all the queues are mutually excluded). Thus we need to acquire-release semantics on the full “chain” of target queues.
This patch changes the way we Acquire() and Release() when executing tasks in queues. Now we’ll walk the chain of target queues and synchronize on each queue that is serial (or when dealing with a barrier block). This should avoid false positives when using dispatch_set_target_queue().
Differential Revision: https://reviews.llvm.org/D25835
llvm-svn: 285613
Otherwise __asan_dynamic_memory_address will be zero during static
initialization and instrumented code will crash immediately.
Fixes PR30810
Patch by David Major
llvm-svn: 285600
ASan dead-strip support relies on a linker option that only exists
in 10.11 and later, so the LLVM instrumentation checks for the deployment
target. This test does not pass when clang is built to choose lower
deployment target by default but runs on newer host.
(Note, the REQUIRES: osx-ld64-live_support clause only checks the host
and not the target OS.)
Differential Revision: https://reviews.llvm.org/D26107
llvm-svn: 285482
The CMake build system had missed this macro as part of the build of the
builtins. This would result in the builtins exporting symbols which are
implemented in assembly with global visibility. Ensure that the assembly
optimized routines are given the same visibility as the C routines.
llvm-svn: 285477
There is a corner case reported in Go issue tracker:
https://github.com/golang/go/issues/17065
On darwin data/bss segments may not be aligned to page bounary
and mmap seems to be behaving differently than on linux
(shrinks instead of enlarge unaligned regions).
Explicitly round shadow to page bounary before mapping
to avoid any such problems.
llvm-svn: 285454
Go maps shadow memory lazily, so we don't have the huge multi-TB mapping.
Virtual memory consumption is proportional to normal memory usage.
Also in Go core dumps are enabled explicitly with GOTRACEBACK=crash,
if user explicitly requests a core that must be on purpose.
So don't disable core dumps by default.
llvm-svn: 285451
Currently we either define SANITIZER_GO for Go or don't define it at all for C++.
This works fine with preprocessor (ifdef/ifndef/defined), but does not work
for C++ if statements (e.g. if (SANITIZER_GO) {...}). Also this is different
from majority of SANITIZER_FOO macros which are always defined to either 0 or 1.
Always define SANITIZER_GO to either 0 or 1.
This allows to use SANITIZER_GO in expressions and in flag default values.
Also remove kGoMode and kCppMode, which were meant to be used in expressions,
but they are not defined in sanitizer_common code, so SANITIZER_GO become prevalent.
Also convert some preprocessor checks to C++ if's or ternary expressions.
Majority of this change is done mechanically with:
sed "s#ifdef SANITIZER_GO#if SANITIZER_GO#g"
sed "s#ifndef SANITIZER_GO#if \!SANITIZER_GO#g"
sed "s#defined(SANITIZER_GO)#SANITIZER_GO#g"
llvm-svn: 285443
Currently windows fails on startup with:
CHECK failed: gotsan.cc:3077 "(((m - prev_m) / kMetaShadowSize)) == (((p - prev) / kMetaShadowCell))" (0x3ffffffeffffff7e, 0x6ffffff7e)
Make MemToMeta do the same MemToShadow does on windows: add offset instead of or'ing it.
llvm-svn: 285420
There is possible deadlock in dynamic ASan runtime when we dlopen() shared lib
which creates a thread at the global initialization stage. The scenario:
1) dlopen grabs a GI_pthread_mutex_lock in main thread.
2) main thread calls pthread_create, ASan intercepts it, calls real pthread_create
and waits for the second thread to be "fully initialized".
3) Newly created thread tries to access a thread local disable_counter in LSan
(to complete its "full initialization") and hangs in tls_get_addr_tail, because
it also tries to acquire GI_pthread_mutex_lock.
The issue is reproducible on relative recent Glibc versions e.g. 2.23.
Differential Revision: https://reviews.llvm.org/D26028
llvm-svn: 285385
Looks like we are missing these flags only in tsan and sanitizer-common.
This results in linker warnings in some settings as it can cause the Unit
tests to be built with a different SDK version than that was used to build
the runtime. For example, we are not setting the minimal deployment target
on the tests but are setting the minimal deployment target for the sanitizer
library, which leads to the following warning on some bots: ld: warning:
object file (sanitizer_posix_test.cc.i386.o) was built for newer OSX version
(10.12) than being linked (10.11).
Differential Revision: https://reviews.llvm.org/D25860https://reviews.llvm.org/D25352
llvm-svn: 285255
Summary:
In order to support 32-bit platforms, we have to make some adjustments in
multiple locations, one of them being the Scudo chunk header. For it to fit on
64 bits (as a reminder, on x64 it's 128 bits), I had to crunch the space taken
by some of the fields. In order to keep the offset field small, the secondary
allocator was changed to accomodate aligned allocations for larger alignments,
hence making the offset constant for chunks serviced by it.
The resulting header candidate has been added, and further modifications to
allow 32-bit support will follow.
Another notable change is the addition of MaybeStartBackgroudThread() to allow
release of the memory to the OS.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25688
llvm-svn: 285209
The test contains a switch statement in which two of the cases are
tail-merged, with the call to __ubsan_handle_dynamic_type_cache_miss_abort
in the common tail. When tail-merging occurs, the debug location of the
tail is randomly taken from one of the merge inputs. Luckily for the test,
the expected line number in the check is the one which is chosen by the
tail-merge. However, if the switch cases are re-ordered the test will
fail.
This patch disables tail-merge, making the test resilient to changes
in tail-merge, and unblocking review D25742. It does not change the
semantics of the test.
llvm-svn: 285208
clear_cache is using R7 for the SVC call and that's the frame pointer in
GCC, which is only disabled on -O2/3, so Release builds finish, Debug don't.
Fixes PR30797.
llvm-svn: 285204
Summary: Newer versions of clang complain that __asan_schedule_unregister_globals is unused. Moving it outside the anonymous namespace gets rid of that warning.
Reviewers: rnk, timurrrr
Subscribers: kubabrecka, dberris
Differential Revision: https://reviews.llvm.org/D25921
llvm-svn: 285010
Darwin's implementation of strstr seems to trigger slightly different failure
modes from Linux since it calls strncmp. All messages seem about equally useful
and correct, so I relaxed the tests so Darwin can pass.
llvm-svn: 285004
This patch replaces fprintf with print_address function
in LSAN tests. This is necessary because of different
printing of pointers in fprintf and sanitizer's print
function. Differential Revision: https://reviews.llvm.org/D25270.
llvm-svn: 284722
This makes __llvm_profile_set_filename() work across dylib boundaries on
Darwin.
This functionality was originally meant to work on all platforms, but
was moved to a Linux-only directory with r272404. The root cause of the
test failure on Darwin was that lprofCurFilename was not marked weak.
Each dylib maintained its own copy of the variable due to the two-level
namespace.
Tested with check-profile (on Darwin). I don't expect this to regress
other platforms.
Differential Revision: https://reviews.llvm.org/D25707
llvm-svn: 284440
Summary:
This change depends on D23986 which adds tail call-specific sleds. For
now we treat them first as normal exits, and in the future leave room
for implementing this as a different kind of log entry.
The reason for deferring the change is so that we can keep the naive
logging implementation more accurate without additional complexity for
reading the log. The accuracy is gained in effectively interpreting call
stacks like:
A()
B()
C()
Which when tail-call merged will end up not having any exit entries for
A() nor B(), but effectively in turn can be reasoned about as:
A()
B()
C()
Although we lose the fact that A() had called B() then had called C()
with the naive approach, a later iteration that adds the explicit tail
call entries would be a change in the log format and thus necessitate a
version change for the header. We can do this later to have a chance at
releasing some tools (in D21987) that are able to handle the naive log
format, then support higher version numbers of the log format too.
Reviewers: echristo, kcc, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D23988
llvm-svn: 284178
Summary:
LeakSanitizer does not work with ptrace but currently it
will print warnings (only under verbosity=1) and then proceed
to print tons of false reports.
This patch makes lsan fail hard under ptrace with a verbose message.
https://github.com/google/sanitizers/issues/728
Reviewers: eugenis, vitalybuka, aizatsky
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D25538
llvm-svn: 284171
Some of our existing tests hang on the new Windows bot with this stack:
770, clang_rt.asan_dynamic-i386.dll!__asan::AsanTSDGet+0x3e
771, clang_rt.asan_dynamic-i386.dll!__asan::GetCurrentThread+0x9
772, clang_rt.asan_dynamic-i386.dll!__asan_handle_no_return+0xe
773, clang_rt.asan_dynamic-i386.dll!__asan_wrap__except_handler4_common+0x12
774, ntdll.dll!wcstombs+0xb0 (No unwind info)
775, ntdll.dll!ZwWow64CallFunction64+0x2001 (No unwind info)
776, ntdll.dll!ZwWow64CallFunction64+0x1fd3 (No unwind info)
777, ntdll.dll!KiUserExceptionDispatcher+0xf (No unwind info)
778, clang_rt.asan_dynamic-i386.dll!destroy_fls+0x13
779, ntdll.dll!RtlLockHeap+0xea (No unwind info)
780, ntdll.dll!LdrShutdownProcess+0x7f (No unwind info)
781, ntdll.dll!RtlExitUserProcess+0x81 (No unwind info)
782, kernel32.dll!ExitProcess+0x13 (No unwind info)
783, clang_rt.asan_dynamic-i386.dll!__sanitizer::internal__exit+0xc
784, clang_rt.asan_dynamic-i386.dll!__sanitizer::Die+0x3d
785, clang_rt.asan_dynamic-i386.dll!__asan::AsanInitInternal+0x50b
786, clang_rt.asan_dynamic-i386.dll!__asan::Allocator::Allocate+0x1c
787, clang_rt.asan_dynamic-i386.dll!__asan::Allocator::Calloc+0x43
We hang because AsanDie tries to defend against multi-threaded death by
infinite looping if someone is already exiting. We might want to
reconsider that, but one easy way to avoid getting here is not to let
our noreturn interceptors call back into fragile parts of ASan.
llvm-svn: 284067
Sanitizers are intentionally not including system headers and often declare slightly different function prototypes, which is incompatible with -fmodules and -fcxx-modules. Let’s simply exclude compiler-rt from using -fmodules.
Differential Revision: https://reviews.llvm.org/D25230
llvm-svn: 283658
Used uptr for __sanitizer_kernel_sigset_t.sig to avoid byte order issues on big endian systems
Reviewd by bruening.
Differential: D24332
llvm-svn: 283438
The VM layout is not stable between iOS version releases, so switch to dynamic shadow offset.
Differential Revision: https://reviews.llvm.org/D25218
llvm-svn: 283375
Reapply 282061.
One of the tests relying on sem_t's layout gets the wrong value for versions of
glibc newer than 2.21 on platforms that don't have 64-bit atomics (e.g. ARM).
This commit fixes the test to work with:
* versions of glibc >= 2.21 on platforms with 64-bit atomics: unchanged
* versions of glibc >= 2.21 on platforms without 64-bit atomics: the semaphore
value is shifted by SEM_VALUE_SHIFT (which is set to 1 in glibc's internal
headers)
* versions of glibc < 2.21: unchanged
The logic is complicated a bit by the fact that the sanitizers always pick the
oldest version of the symbol available in glibc, which creates discrepancies
between old platforms which contain several versions od the sem_init symbol, and
newer platforms which contain only one.
See the glibc 2.23 sources:
* sysdeps/nptl/internaltypes.h (struct new_sem for glibc >= 2.21 and
struct old_sem for glibc < 2.21)
* nptl/sem_getvalue.c
This was uncovered on one of the new buildbots that we are trying to move to
production.
Differential Revision: https://reviews.llvm.org/D24766
llvm-svn: 283299
The VM layout is not stable between iOS version releases, so switch to dynamic shadow offset.
Differential Revision: https://reviews.llvm.org/D25218
llvm-svn: 283240
Summary:
Handles early allocation from dlsym by allocating memory from a local
static buffer.
Reviewers: bruening
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D25193
llvm-svn: 283139
Summary:
s/CHECK_LT/CHECK_LE/ in the secondary allocator, as under certain circumstances
Ptr + Size can be equal to MapEnd. This edge case was not found by the current
tests, so those were extended to be able to catch that.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25101
llvm-svn: 282913
Summary:
The check-asan-dynamic tests were broken on win10 because the interception
library was not able to hook on some functions.
credits: thanks sebastian marchand to help debugging this on win10.
Reviewers: rnk
Subscribers: chrisha, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D25120
llvm-svn: 282904
Summary:
This patch is adding support for dynamic shadow allocation.
This is a merge and re-commit of the following patches.
```
[compiler-rt] Fix Asan build on Android
https://reviews.llvm.org/D24768
[compiler-rt] Add support for the dynamic shadow allocation
https://reviews.llvm.org/D23363
```
This patch needed to re-land at the same time:
```
[asan] Support dynamic shadow address instrumentation
https://reviews.llvm.org/D23354
```
Reviewers: rnk, zaks.anna
Subscribers: tberghammer, danalbert, kubabrecka, dberris, chrisha, llvm-commits
Differential Revision: https://reviews.llvm.org/D25104
llvm-svn: 282882
Summary:
This test is broken on wndows 64-bit.
The interception library is not able to hook on the memchr functions.
Snippet of the function that is not hookable:
```
--- No source file -------------------------------------------------------------
000007FEFA1A18CD CC int 3
000007FEFA1A18CE CC int 3
000007FEFA1A18CF CC int 3
--- f:\dd\vctools\crt\vcruntime\src\string\amd64_arm_arm64\memchr.c ------------
while ( cnt && (*(unsigned char *)buf != (unsigned char)chr) ) {
000007FEFA1A18D0 4D 85 C0 test r8,r8
000007FEFA1A18D3 74 0D je memchr+12h (07FEFA1A18E2h)
000007FEFA1A18D5 38 11 cmp byte ptr [rcx],dl
000007FEFA1A18D7 74 09 je memchr+12h (07FEFA1A18E2h)
buf = (unsigned char *)buf + 1;
000007FEFA1A18D9 48 FF C1 inc rcx
cnt--;
000007FEFA1A18DC 49 83 E8 01 sub r8,1
000007FEFA1A18E0 75 F3 jne memchr+5h (07FEFA1A18D5h)
}
```
Reviewers: rnk
Subscribers: kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D25037
llvm-svn: 282860
Summary:
On windows, the memcpy and memmove function can be the same.
This is correcly detected when hooking, but it's not possible
to report the right function name when doing symbolisation.
The same fix was applied for the static asan unittest.
We forgot to apply the fix for the dynamic asan tests.
```
lvm\projects\compiler-rt\test\asan/TestCases/Windows/.svn/text-base/intercept_memcpy.cc.svn-base:// CHECK-NEXT: __asan_{{.*}}mem{{.*}}
```
This patch is fixing this test (win64):
```
ddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memcpy_indirect.cc
```
Reviewers: rnk, vitalybuka
Subscribers: llvm-commits, kubabrecka, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D25038
llvm-svn: 282859
Summary:
The MSVC compiler is generating multiple instance of the exception handler
when compiling on win64 with /MD.
see: https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
Two tests were failing when running:
```
ninja check-asan-dynamic.
```
The tests were failing because only the first occurence of the function was patched.
The function `__C_specific_handler` is defined in `ntdll` and `vcruntime140`.
After this patch, there is still two remaining tests failing.
```
********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 87.81s
********************
Failing Tests (2):
AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memchr.cc
AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memcpy_indirect.cc
Expected Passes : 342
Passes With Retry : 2
Expected Failures : 16
Unsupported Tests : 152
Unexpected Failures: 2
```
Reviewers: rnk, vitalybuka
Subscribers: vitalybuka, llvm-commits, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D24983
llvm-svn: 282614
This patch extends __sanitizer_finish_switch_fiber method to optionally return previous stack base and size.
This solves the problem of coroutines/fibers library not knowing the original stack context from which the library is used. It's incorrect to assume that such context is always the default stack of current thread (e.g. one such library may be used from a fiber/coroutine created by another library). Bulding a separate stack tracking mechanism would not only duplicate AsanThread, but also require each coroutines/fibers library to integrate with it.
Author: Andrii Grynenko (andriigrynenko)
Reviewed in: https://reviews.llvm.org/D24628
llvm-svn: 282582
This is a follow up to r282152.
A more extensive testing on real apps revealed a subtle bug in r282152.
The revision made shadow mapping non-linear even within a single
user region. But there are lots of code in runtime that processes
memory ranges and assumes that mapping is linear. For example,
region memory access handling simply increments shadow address
to advance to the next shadow cell group. Similarly, DontNeedShadowFor,
java memory mover, search of heap memory block header, etc
make similar assumptions.
To trigger the bug user range would need to cross 0x008000000000 boundary.
This was observed for a module data section.
Make shadow mapping linear within a single user range again.
Add a startup CHECK for linearity.
llvm-svn: 282405
Don't xor user address with kAppMemXor in meta mapping.
The only purpose of kAppMemXor is to raise shadow for ~0 user addresses,
so that they don't map to ~0 (which would cause overlap between
user memory and shadow).
For meta mapping we explicitly add kMetaShadowBeg offset,
so we don't need to additionally raise meta shadow.
llvm-svn: 282403
It's wrong to pass to MsanReallocate a pointer that MSan allocator doesn't own.
Use nullptr instead of ptr to prevent possible (still unlikely) failure.
llvm-svn: 282390
This reverts commit r282294. It breaks a Linux bot:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/12180
It looks like the test checks that __llvm_profile_set_filename() alters the raw
profile filename in both the dylib and the main program. Now that
lprofCurFilename is hidden, this can't work, and we get two profiles (one for
the call to "main" and one for "func").
Back this change out so that we don't affect external users.
llvm-svn: 282304
Profile-aarch64 :: Linux/comdat_rename.test
Profile-aarch64 :: Linux/extern_template.test
Profile-aarch64 :: Linux/instrprof-comdat.test
Profile-aarch64 :: Linux/instrprof-cs.c
The issue is that the created (aarch64) binaries were attempting to run natively
instead of running through %run, which guarantees running in the proper
environment if the compilation was configured correctly.
llvm-svn: 282264
Summary:
The 'asan_preload_test-1.cc' is not working with the i686 architecture.
To repro the error, run on a linux 64-bit:
```
ninja check-asan-dynamic
```
The following error occurs:
```
--
Exit Code: 1
Command Output (stderr):
--
/home/llvm/llvm/projects/compiler-rt/test/asan/TestCases/Linux/asan_preload_test-1.cc:18:12: error: expected string not found in input
// CHECK: AddressSanitizer: heap-buffer-overflow
^
<stdin>:1:1: note: scanning from here
ERROR: ld.so: object 'libclang_rt.asan-i686.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
^
<stdin>:2:10: note: possible intended match here
==25982==AddressSanitizer CHECK failed: /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:736 "((__interception::real_memcpy)) != (0)" (0x0, 0x0)
```
The unittest is running (where %shared_libasan is replaced by libclang_rt.asan-i686.so):
```
// RUN: env LD_PRELOAD=%shared_libasan not %run %t 2>&1 | FileCheck %s
```
But the executable also has a dependancy on libclang_rt.asan-i386.so (added by the clang driver):
```
linux-gate.so.1 => (0xf77cc000)
libclang_rt.asan-i386.so => not found
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf76ba000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7673000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7656000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf74a7000)
```
By looking to the clang driver (tools.cpp) we can see that every x86 architecture are mapped to 'i386'.
```
StringRef MyArch;
switch (getToolChain().getArch()) {
case llvm::Triple::arm:
MyArch = "arm";
break;
case llvm::Triple::x86:
MyArch = "i386";
break;
case llvm::Triple::x86_64:
MyArch = "amd64";
break;
default:
llvm_unreachable("Unsupported architecture");
}
```
This patch is implementing the same mapping but in the compiler-rt unittest.
Reviewers: rnk, vitalybuka
Subscribers: aemerson, kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D24838
llvm-svn: 282263
On Darwin, -lm, -pthread and others are implied. -pthread currently produces a warning (compiler option unused).
Differential Revision: https://reviews.llvm.org/D24698
llvm-svn: 282260
Summary:
Window compiler is stricter for attributes location. This patch fixes a compilation error.
```
D:\src\llvm\llvm\projects\compiler-rt\lib\lsan\lsan_thread.cc(39): error C2144: syntax error: 'int' should be preceded by ';'
```
Reviewers: rnk, majnemer
Subscribers: majnemer, llvm-commits, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D24810
llvm-svn: 282254
In ShadowToMem we call MemToShadow potentially for incorrect addresses.
So DCHECK(IsAppMem(p)) can fire in debug mode.
Fix this by swapping range and MemToShadow checks.
llvm-svn: 282157
4.1+ Linux kernels map pie binaries at 0x55:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90
Currently tsan does not support app memory at 0x55 (https://github.com/google/sanitizers/issues/503).
Older kernels also map pie binaries at 0x55 when ASLR is disables (most notably under gdb).
This change extends tsan mapping for linux/x86_64 to cover 0x554-0x568 app range and fixes both 4.1+ kernels and gdb.
This required to slightly shrink low and high app ranges and move heap. The mapping become even more non-linear, since now we xor lower bits. Now even a continuous app range maps to split, intermixed shadow ranges. This breaks ShadowToMemImpl as it assumes linear mapping at least within a continuous app range (however it turned out to be already broken at least on arm64/42-bit vma as uncovered by r281970). So also change ShadowToMemImpl to hopefully a more robust implementation that does not assume a linear mapping.
llvm-svn: 282152
For mips assember '#' is the start of comment. We get assembler error messages if # is used in the struct names. Therefore using '$' which works for all architectures.
Differential: D24335
Reviewed by: zhaoqin
llvm-svn: 282142
Summary:
Finish work on PR30351 (last one, after D24551, D24552, and D24554 land)
Also replace the old ReportData structure/variable with the current_error_ static
member of the ScopedInErrorReport class.
This has the following side-effects:
- Move ASAN_ON_ERROR(); call to the start of the destructor, instead
of in StartReporting().
- We only generate the error structure after the
ScopedInErrorReport constructor finishes, so we can't call
ASAN_ON_ERROR() during the constructor. I think this makes more
sense, since we end up never running two of the ASAN_ON_ERROR()
callback. This also works the same way as error reporting, since
we end up having a lock around it. Otherwise we could end up
with the ASAN_ON_ERROR() call for error 1, then the
ASAN_ON_ERROR() call for error 2, and then lock the mutex for
reporting error 1.
- The __asan_get_report_* functions will be able to, in the future,
provide information about other errors that aren't a "generic
error". But we might want to rethink that API, since it's too
restricted. Ideally we teach lldb about the current_error_ member of
ScopedInErrorReport.
Reviewers: vitalybuka, kcc, eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D24555
llvm-svn: 282107
Summary:
The dynamic shadow code is not detected correctly on Android.
The android shadow seems to start at address zero.
The bug is introduced here:
https://reviews.llvm.org/D23363
Started here: https://build.chromium.org/p/chromium.fyi/builders/ClangToTAndroidASan/builds/4029
Likely due to an asan runtime change, filed https://llvm.org/bugs/show_bug.cgi?id=30462
From asan_mapping.h:
```
#if SANITIZER_WORDSIZE == 32
# if SANITIZER_ANDROID
# define SHADOW_OFFSET (0) <<---- HERE
# elif defined(__mips__)
```
Shadow address on android is 0.
From asan_rtl.c:
```
if (shadow_start == 0) {
[...]
shadow_start = FindAvailableMemoryRange(space_size, alignment, granularity);
}
```
We assumed that 0 is dynamic address.
On windows, the address was determined with:
```
# elif SANITIZER_WINDOWS64
# define SHADOW_OFFSET __asan_shadow_memory_dynamic_address
# else
```
and __asan_shadow_memory_dynamic_address is initially zero.
Reviewers: rnk, eugenis, vitalybuka
Subscribers: kcc, tberghammer, danalbert, kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D24768
llvm-svn: 282085
One of the tests relying on sem_t's layout gets the wrong value for versions of
glibc newer than 2.21 on platforms that don't have 64-bit atomics (e.g. ARM).
This commit fixes the test to work with:
* versions of glibc >= 2.21 on platforms with 64-bit atomics: unchanged
* versions of glibc >= 2.21 on platforms without 64-bit atomics: the semaphore
value is shifted by SEM_VALUE_SHIFT (which is set to 1 in glibc's internal
headers)
* versions of glibc < 2.21: unchanged
See the glibc 2.23 sources:
* sysdeps/nptl/internaltypes.h (struct new_sem for glibc >= 2.21 and
struct old_sem for glibc < 2.21)
* nptl/sem_getvalue.c
This was uncovered on one of the new buildbots that we are trying to move to
production.
Differential Revision: https://reviews.llvm.org/D24766
llvm-svn: 282061
This was changed in rL276151 and causes problems if the C++ compiler does not
support the same arches as the C compiler.
For the builtins, only the C compiler is tested in try_compile_only.
Additionally, -fno-exceptions is passed in (if available) to work around
the case where no libunwind is available.
Differential Revision: https://reviews.llvm.org/D23654
llvm-svn: 282054
Summary:
GetActuallyAllocatedSize() was not accounting for the last page of the mapping
being a guard page, and was returning the wrong number of actually allocated
bytes, which in turn would mess up with the realloc logic. Current tests didn't
find this as the size exercised was only serviced by the Primary.
Correct the issue by subtracting PageSize, and update the realloc test to
exercise paths in both the Primary and the Secondary.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24787
llvm-svn: 282030
Summary:
Much of the non-Darwin build system assumes that COMPILER_RT_DEFAULT_TARGET_TRIPLE is the default target triple for the compiler being used. With clang as your compiler this isn't necessarily true.
To ensure that the rest of the build system behaves as expected this patch adds "--target=${COMPILER_RT_DEFAULT_TARGET_TRIPLE}" to the compiler flags for C, CXX and ASM sources.
Reviewers: compnerd, rengolin, fjricci
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24156
llvm-svn: 282024
Summary:
The Sanitizer Secondary Allocator was not entirely ideal was Scudo for several
reasons: decent amount of unneeded code, redundant checks already performed by
the front end, unneeded data structures, difficulty to properly protect the
secondary chunks header.
Given that the second allocator is pretty straight forward, Scudo will use its
own, trimming all the unneeded code off of the Sanitizer one. A significant
difference in terms of security is that now each secondary chunk is preceded
and followed by a guard page, thus mitigating overflows into and from the
chunk.
A test was added as well to illustrate the overflow & underflow situations
into the guard pages.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24737
llvm-svn: 281938
Summary:
This patch is adding the needed code to compiler-rt to support
dynamic shadow.
This is to support this patch:
https://reviews.llvm.org/D23354
It's adding support for using a shadow placed at a dynamic address determined
at runtime.
The dynamic shadow is required to work on windows 64-bits.
Reviewers: rnk, kcc, vitalybuka
Subscribers: kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D23363
llvm-svn: 281909
Currently, when doing a ASanified build of LLVM (with Clang, compiler-rt and libcxx) via -DLLVM_USE_SANITIZER=Address and not using any other options, we already disable building of sanitizer runtimes (because they themselves can’t be sanitized) and also exclude the sanitizer tests. However, the same is not done for the profiling runtime, which will build fine, but then all the tests fail due to linking errors. Let’s disable the profiling runtime as well (when LLVM_USE_SANITIZER is set).
Differential Revision: https://reviews.llvm.org/D24657
llvm-svn: 281815
Summary:
This value is already defaulted to true in asan_internal.h.
Allow the value to be overriden in cases where exceptions are unavailable.
Reviewers: kcc, samsonov, compnerd
Subscribers: kubabrecka, dberris, beanz, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D24633
llvm-svn: 281746
Summary:
I need to redu solution, existing is not good enough.
PR28267
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24490
llvm-svn: 281687
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
These got out of sync and the tests were failing for me locally. We
assume a 47 bit address space in ASan, so we should do the same in the
tests.
llvm-svn: 281622
Don't list __sanitizer_print_memory profile as an INTERFACE_FUNCTION. It
is not exported by ASan; it is exported by user code.
Move the weak definition from asan_win.cc to sanitizer_win.cc to fix the
ubsan tests.
llvm-svn: 281619
Summary:
ASAN on Windows 64-bits should use a dynamic address instead of a fixed one.
The asan-allocator code to support dynamic address is already landed.
This patch is turning on the feature.
Reviewers: rnk
Subscribers: kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D24575
llvm-svn: 281522
The '-asan-use-private-alias’ option (disabled by default) option is currently only enabled for Linux and ELF, but it also works on Darwin and Mach-O. This option also fixes a known problem with LTO on Darwin (https://github.com/google/sanitizers/issues/647). This patch enables the support for Darwin (but still keeps it off by default) and adds the LTO test case.
Differential Revision: https://reviews.llvm.org/D24292
llvm-svn: 281472
Support overriding LLVM_* variables obtained from llvm-config when doing
stand-alone builds. The override of LLVM_MAIN_SRC_DIR is necessary to
provide LLVM sources when the initial directory used to build LLVM does
no longer exist when compiler-rt is built stand-alone. This is
especially the case when building the projects separately in temporary
directories with unpredictable names.
The code is based on existing CMakeLists.txt from clang. Alike clang, it
extends the override to all queried variables.
Differential Revision: https://reviews.llvm.org/D24005
llvm-svn: 281461
It makes the tests extremely slow due to high latency of the test launcher.
The main reason for -j5 was high memory usage with handle_abort=1, which
is now disabled in the test runner.
llvm-svn: 281409
When running with start_deactivated=1 in ASAN_OPTIONS, heap redzones
are not poisoned until the first instrumented module is loaded. This
can cause false negatives even on memory allocated after activation,
because redzones are normally poisoned only once when a new allocator
region is mapped.
This change attempts to fix it by iterating over all existing
allocator chunks and poisoning their redzones.
llvm-svn: 281364
Summary:
Added a macro to enumerate the (error name, error member name) pairs. This way,
when adding an error, we only need to add the pair to one place (plus add its
implementation, or course).
Reviewers: kcc, samsonov
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23875
llvm-svn: 281237
Summary: As mentioned in D24394, I'm moving tid to ErrorBase, since basically all errors need it.
Also mentioned in the same review are other cleanups like adding const
to BufferedStackTrace and make sure constructor orders are consistent.
Reviewers: vitalybuka, kcc, eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24455
llvm-svn: 281236
Summary:
This is important information when we want to describe errors, and should be
part of these descriptions. Otherwise, we need to know the access size when
printing/emitting the description.
Reviewers: kcc, eugenis, vitalybuka
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24387
llvm-svn: 281093
Summary:
This is useful for inclusion in the Error* structures, to describe an
arbitrary address.
Remove the old struct since it's used only once. This removes one level of
indirection, and moves all *AddressDescription to be one of the recently
introduced structures.
This merges differential revisions: D24131 and D24132
Reviewers: kcc, eugenis, vitalybuka
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D24131
llvm-svn: 281090
The same thing is already done on Mac. handle_abort slows down tests
significantly because it triggers tombstone collection on Android;
also, it changes failed test outcome from "not-crash" to "crash" (as
in "bin/not --crash").
This change adds handle_abort=0 to asan options on android (test
only!), and also tweaks android_run.py to semi-correctly pass the
crash/no-crash status to the caller.
llvm-svn: 281075
Summary: Merges back both scariness_score_test.cc files, since the Linux-specific version shouldn't be needed any more.
Reviewers: kcc, eugenis, vitalybuka
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24347
llvm-svn: 281048
Summary: This flag doesn't make sense on Windows systems.
Reviewers: beanz, kubabrecka, compnerd
Subscribers: dberris, llvm-commits, beanz
Differential Revision: https://reviews.llvm.org/D24320
llvm-svn: 280953
r280885 added a testcase for handle_abort, which is broken on macOS, let’s add this support into sanitizer_mac.cc.
Differential Revision: https://reviews.llvm.org/D24344
llvm-svn: 280945
This patch adds a wrapper for call_once, which uses an already-compiled helper __call_once with an atomic release which is invisible to TSan. To avoid false positives, the interceptor performs an explicit atomic release in the callback wrapper.
Differential Revision: https://reviews.llvm.org/D24188
llvm-svn: 280920
Reset the SIGABRT signal handler before calling abort().
Also, change the error message when catching SIGABRT to say "ABRT"
instead of "SEGV".
llvm-svn: 280885
On Linux ARM, the syscall will take 3 arguments (start, end, flags). Ensure
that we do not pass garbage to the flags, which can cause the cacheflush call to
fail, and therefore cause an abort at runtime.
llvm-svn: 280877
Android-specific code in GetCurrentThread() does not handle the situation when there is no
ThreadContext for the current thread. This happens if the current thread is requested before the
main thread is added to the registry. 64-bit allocator does that to record map/unmap stats during
initialization.
llvm-svn: 280876
Normally, syslog() uses argv[0] for the log tag; bionic, however,
would crash in syslog() before libc constructor unless the log
tag is explicitly set with openlog().
llvm-svn: 280875
Summary:
A few small changes required to permit building the sanitizers
with Clang instead of only with MSVC.
Reviewers: compnerd, beanz, rnk
Subscribers: beanz, timurrrr, kubabrecka, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D24092
llvm-svn: 280863
Summary:
Make sure that windows libraries contain the suffixes expected by clang.
This is expecially important when compiling the windows builtins with
clang, as cmake will use .a as the suffix by default.
Reviewers: beanz, compnerd
Subscribers: llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D24046
llvm-svn: 280854
Since r279664 this test causes frequent failures of test runs for ppc64le and
occasional failures for ppc64be which makes buildbot results unreliable. If
the underlying problem is fixed it can be re-enabled.
llvm-svn: 280823
With this patch 10 out of 13 tests are passing.
Following is the list of failing tests:
struct-simple.cpp
workingset-signal-posix.cpp
mmap-shadow-conflict.c
Reviewed by bruening
Differential: D23799
llvm-svn: 280795
When optimizing, GCC optimizes away aggressively unused static globals.
The __asan_before_dynamic_init/__asan_after_dynamic_init calls are placed
in static constructor earlier while the registration of the globals is done
later in the compilation process. If all the globals with
dynamic initialization are optimized away from some particular TU in between
those two, libasan can fail on an assertion that dynamic_init_globals is
empty.
While I'm going to commit a GCC change which will remove the
__asan_before_dynamic_init/__asan_after_dynamic_init in many cases when this
happens (basically if the optimizers can prove there are no memory
references in between the two calls), there are still testcases where such
pair of calls is left, e.g. for
struct S { S () { asm volatile ("" : : : "memory"); } };
static S c;
int
main ()
{
return 0;
}
with -O2 -fsanitize=address and ASAN_OPTIONS=check_initialization_order=true
this still fails the assertion. Trying to avoid this problem on the
compiler side would decrease code quality I'm afraid, whether it is making
sure for -fsanitize=address we keep around at least one dynamically
initialized global if the
__asan_before_dynamic_init/__asan_after_dynamic_init pair has been emitted,
or adding some artificial global which would be used as the condition for
those calls etc.
So, can the assertion be instead just removed, this really shouldn't slow
down the calls measurably (for __asan_before_dynamic_init it is even
cheaper) and the assertion doesn't check something worthwhile anyway (it is
sufficient if there is a single dynamically initialized global in any other
TU to make it happy).
Details in http://gcc.gnu.org/PR77396
Author: Jakub Jelinek
llvm-svn: 280657
Summary:
Only one of the tests in it doesn't work on OS X.
On Windows it seems that everything that is being moved is also
supported.
The abort() test wasn't copied over (original case 22). This is because
it doesn't work on OS X.
Reviewers: kcc, eugenis, vitalybuka
Subscribers: kubabrecka, llvm-commits
llvm-svn: 280469
The atomic builtin source is problematic when cross-compiling builtins because it requires a variable and sometimes large set of system headers. This option allows users to optionally prevent it from being built.
llvm-svn: 280416
There was an invalid entry in the sanitizer list, remove it. This has no effect
on the building, just removes the definition of a cached variable.
llvm-svn: 280378
Another CFG optimisation patch (280364) has broken bad profile tests, and this
is a similar attempt to fix the test without changing the semantics.
llvm-svn: 280373
Commit r280364 has introduced some call-graph optmisations making a profiler
test "fail" due to not expecting the compiler to be "smart", and fold constants
across functions. This commit works around the issue, leaving the origial
semantics intact.
llvm-svn: 280365
The abort() test wasn't copied over (original case 22). This is because
it doesn't work on OS X.
If theres no buildbot problem with this test later today, I will
minimize the Linux version.
llvm-svn: 280361
Summary:
@kcc: I know you've accepted the other revision, but since this is a
non-trivial change, I'm updating it to show why D24029 would help.
This commit sets up the infrastructure to use reified error
descriptions, and moves ReportStackOverflow to the new system.
After we convert all the errors, we'll be able to simplify ScopedInErrorReport
and remove the older debugging mechanism which had some errors partly reified
in some way. We'll be able to maintain the external API.
ScopedInErrorReport will be able to track one of the reified errors at a time.
The purpose of this is so we have its destructor actually print the error and
possibly interface with the debugger (will depend on the platform, of course).
Reviewers: kcc, samsonov, timurrrr
Subscribers: kcc, llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24030
llvm-svn: 280111
Summary:
This is needed so we can use it for D23672 on VS2013, since this VS
version doesn't support unrestricted unions, and doesn't allow us to
uses an object without a trivial default constructor inside a union.
Reviewers: kcc, samsonov
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D24029
llvm-svn: 280110
Summary:
We are going to use store instructions to poison some allocas.
Runtime flag will require branching in instrumented code on every lifetime
intrinsic. We'd like to avoid that.
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23967
llvm-svn: 279981
Kostya Serebryany