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
Filipe Cabecinhas