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
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
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
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
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
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:
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: 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
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
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
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
Martin Storsjo