Summary:
Stop using directly sysctl(3) routines in sanitizer_procmaps_bsd
and replace it with internal_sysctl().
This will allow to install interceptors for sysctl(3).
Reviewers: joerg, vitalybuka
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D52646
llvm-svn: 343370
This seems to cause the thread's exit code to be clobbered, breaking
Chromium tests.
Also revert follow-up r342654.
> In long-running builds we've seen some ASan complaints during thread creation that we suspect are due to leftover poisoning from previous threads whose stacks occupied that memory. This patch adds a hook that unpoisons the stack just before the NtTerminateThread syscall.
>
> Differential Revision: https://reviews.llvm.org/D52091
llvm-svn: 343322
Summary:
Currently,
cd test/xray/TestCases/Posix
$build/bin/llvm-lit fdr-thread-order.cc
fails because `rm fdr-thread-order.*` deletes the .cc file.
This patch uses:
* %t as temporary directory name containing log files
* %t.exe as executable name
It does not delete %t after the test finishes for debugging convenience.
This matches the behavior of tests of various other LLVM components.
Log files will not clog up because the temporary directory (unique among
test files but the same among multiple invocations of a test) is cleaned
at the beginning of the test.
Reviewers: dberris, mboerger, eizan
Reviewed By: dberris
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D52638
llvm-svn: 343295
Summary:
This is for coding standard conformance, and for fixing an ODR violation
issue: __xray::ThreadLocalData is defined twice and differently in
xray_fdr_logging.cc and xray_basic_logging.cc
Reviewers: dberris, mboerger, eizan
Reviewed By: dberris
Subscribers: delcypher, jfb, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D52639
llvm-svn: 343289
Summary:
This change allows us to use the library path from which the LLVM
libraries are installed, in case the LLVM installation generates shared
libraries.
This should address llvm.org/PR39070.
Reviewers: mboerger, eizan
Subscribers: mgorny, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D52597
llvm-svn: 343280
Summary:
The default values used for Space/Size for the new SizeClassMap do not work
with Android. The Compact map appears to be in the same boat.
Disable the test on Android for now to turn the bots green, but there is no
reason Compact & Dense should not have an Android test.
Added a FIXME, I will revisit this soon.
Reviewers: eugenis
Subscribers: srhines, kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D52623
llvm-svn: 343252
Summary:
_Note_: I am not attached to the name `DenseSizeClassMap`, so if someone has a
better idea, feel free to suggest it.
The current pre-defined `SizeClassMap` hold a decent amount of cached entries,
either in cheer number of, or in amount of memory cached.
Empirical testing shows that more compact per-class arrays (whose sizes are
directly correlated to the number of cached entries) are beneficial to
performances, particularly in highly threaded environments.
The new proposed `SizeClassMap` has the following properties:
```
c00 => s: 0 diff: +0 00% l 0 cached: 0 0; id 0
c01 => s: 16 diff: +16 00% l 4 cached: 8 128; id 1
c02 => s: 32 diff: +16 100% l 5 cached: 8 256; id 2
c03 => s: 48 diff: +16 50% l 5 cached: 8 384; id 3
c04 => s: 64 diff: +16 33% l 6 cached: 8 512; id 4
c05 => s: 80 diff: +16 25% l 6 cached: 8 640; id 5
c06 => s: 96 diff: +16 20% l 6 cached: 8 768; id 6
c07 => s: 112 diff: +16 16% l 6 cached: 8 896; id 7
c08 => s: 128 diff: +16 14% l 7 cached: 8 1024; id 8
c09 => s: 144 diff: +16 12% l 7 cached: 7 1008; id 9
c10 => s: 160 diff: +16 11% l 7 cached: 6 960; id 10
c11 => s: 176 diff: +16 10% l 7 cached: 5 880; id 11
c12 => s: 192 diff: +16 09% l 7 cached: 5 960; id 12
c13 => s: 208 diff: +16 08% l 7 cached: 4 832; id 13
c14 => s: 224 diff: +16 07% l 7 cached: 4 896; id 14
c15 => s: 240 diff: +16 07% l 7 cached: 4 960; id 15
c16 => s: 256 diff: +16 06% l 8 cached: 4 1024; id 16
c17 => s: 320 diff: +64 25% l 8 cached: 3 960; id 49
c18 => s: 384 diff: +64 20% l 8 cached: 2 768; id 50
c19 => s: 448 diff: +64 16% l 8 cached: 2 896; id 51
c20 => s: 512 diff: +64 14% l 9 cached: 2 1024; id 48
c21 => s: 640 diff: +128 25% l 9 cached: 1 640; id 49
c22 => s: 768 diff: +128 20% l 9 cached: 1 768; id 50
c23 => s: 896 diff: +128 16% l 9 cached: 1 896; id 51
c24 => s: 1024 diff: +128 14% l 10 cached: 1 1024; id 48
c25 => s: 1280 diff: +256 25% l 10 cached: 1 1280; id 49
c26 => s: 1536 diff: +256 20% l 10 cached: 1 1536; id 50
c27 => s: 1792 diff: +256 16% l 10 cached: 1 1792; id 51
c28 => s: 2048 diff: +256 14% l 11 cached: 1 2048; id 48
c29 => s: 2560 diff: +512 25% l 11 cached: 1 2560; id 49
c30 => s: 3072 diff: +512 20% l 11 cached: 1 3072; id 50
c31 => s: 3584 diff: +512 16% l 11 cached: 1 3584; id 51
c32 => s: 4096 diff: +512 14% l 12 cached: 1 4096; id 48
c33 => s: 5120 diff: +1024 25% l 12 cached: 1 5120; id 49
c34 => s: 6144 diff: +1024 20% l 12 cached: 1 6144; id 50
c35 => s: 7168 diff: +1024 16% l 12 cached: 1 7168; id 51
c36 => s: 8192 diff: +1024 14% l 13 cached: 1 8192; id 48
c37 => s: 10240 diff: +2048 25% l 13 cached: 1 10240; id 49
c38 => s: 12288 diff: +2048 20% l 13 cached: 1 12288; id 50
c39 => s: 14336 diff: +2048 16% l 13 cached: 1 14336; id 51
c40 => s: 16384 diff: +2048 14% l 14 cached: 1 16384; id 48
c41 => s: 20480 diff: +4096 25% l 14 cached: 1 20480; id 49
c42 => s: 24576 diff: +4096 20% l 14 cached: 1 24576; id 50
c43 => s: 28672 diff: +4096 16% l 14 cached: 1 28672; id 51
c44 => s: 32768 diff: +4096 14% l 15 cached: 1 32768; id 48
c45 => s: 40960 diff: +8192 25% l 15 cached: 1 40960; id 49
c46 => s: 49152 diff: +8192 20% l 15 cached: 1 49152; id 50
c47 => s: 57344 diff: +8192 16% l 15 cached: 1 57344; id 51
c48 => s: 65536 diff: +8192 14% l 16 cached: 1 65536; id 48
c49 => s: 81920 diff: +16384 25% l 16 cached: 1 81920; id 49
c50 => s: 98304 diff: +16384 20% l 16 cached: 1 98304; id 50
c51 => s: 114688 diff: +16384 16% l 16 cached: 1 114688; id 51
c52 => s: 131072 diff: +16384 14% l 17 cached: 1 131072; id 48
c53 => s: 64 diff: +0 00% l 0 cached: 8 512; id 4
Total cached: 864928 (152/432)
```
It holds a bit less of 1MB of cached entries at most, and the cache fits in a
page.
The plan is to use this map by default for Scudo once we make sure that there
is no unforeseen impact for any of current use case.
Benchmarks give the most increase in performance (with Scudo) when looking at
highly threaded/contentious environments. For example, rcp2-benchmark
experiences a 10K QPS increase (~3%), and a decrease of 50MB for the max RSS
(~10%). On platforms like Android where we only have a couple of caches,
performance remain similar.
Reviewers: eugenis, kcc
Reviewed By: eugenis
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D52371
llvm-svn: 343246
Summary:
-lm is needed for these tests on Linux, but the lit config for this package automatically adds it for Linux and excludes it for Windows. So we should be able to get these tests running again by just dropping -lm and let the lit config add it when possible.
I was under the impression that -lm worked across platforms because it exists in other tests without and 'UNSUPPORTED: windows' commands (e.g. divsc3_test.c), but those are actually excluded because they 'REQUIRES: c99-complex' which is excluded from windows platforms (also by the local lit config).
I don't have easy access to a windows machine to verify this patch, but I can trigger a build bot run on clang-x64-ninja-win7 shortly after submitting.
Reviewers: hans
Subscribers: dberris, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D52563
llvm-svn: 343245
The `--target` option is rejected by GCC starting from version 7.0.
It's shorter and more portable to use `mabi` option to select MIPS ABI
for testing target architecture. Clang supports that starting from r343169.
llvm-svn: 343182
sancov.py relies on objdump -d to obtain the number of instrumented PCs.
The i386 %dynamiclib will now include .plt entries that are not recognized by objdump,
"sancov.py: found 0 instrumented PCs in *.so",
causing AddressSanitizer-i386-linux to fail.
Change it back to x86-target-arch after %sancov switches to a more robust approach.
llvm-svn: 343178
A version of AndroidGetApiLevel for static executables that is
completely compile-time.
The generic version uses dl_iterate_phdr which, even though it works
in static executables, crashes if called before libc is initialized.
llvm-svn: 343153
In MinGW mode, the /export: directives in object files are interpreted
differently; the symbols are not assumed to be decorated.
Since the GNU linker doesn't support the /alternatename and /include
directives, there's no such distinction for them in lld. This assumes
that the resulting sanitizer libraries will be linked by lld.
Differential Revision: https://reviews.llvm.org/D51882
llvm-svn: 343015
Instead provide manual declarations of the used types, to avoid
pulling in conflicting declarations of some of the functions that
are to be overridden.
Differential Revision: https://reviews.llvm.org/D51914
llvm-svn: 343014
The MinGW headers do define _M_IX86 (contrary to clang-cl and
MSVC where it is a compiler predefined macro), but the headers that
define it aren't included here.
Also check these defines for setting the symbol prefix, instead of
inconsistently using _WIN64 for that.
Differential Revision: https://reviews.llvm.org/D51883
llvm-svn: 343013
Summary: The gcda need to be delete before running the binary to avoid to have an increasing "# of Runs" when a test is failing
Reviewers: vitalybuka, eugenis, marco-c
Reviewed By: marco-c
Subscribers: delcypher, llvm-commits, #sanitizers, sylvestre.ledru, marco-c
Differential Revision: https://reviews.llvm.org/D52456
llvm-svn: 342963
Summary:
Display a list of recent stack frames (not a stack trace!) when
tag-mismatch is detected on a stack address.
The implementation uses alignment tricks to get both the address of
the history buffer, and the base address of the shadow with a single
8-byte load. See the comment in hwasan_thread_list.h for more
details.
Developed in collaboration with Kostya Serebryany.
Reviewers: kcc
Subscribers: srhines, kubamracek, mgorny, hiraditya, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D52249
llvm-svn: 342923
Summary:
Display a list of recent stack frames (not a stack trace!) when
tag-mismatch is detected on a stack address.
The implementation uses alignment tricks to get both the address of
the history buffer, and the base address of the shadow with a single
8-byte load. See the comment in hwasan_thread_list.h for more
details.
Developed in collaboration with Kostya Serebryany.
Reviewers: kcc
Subscribers: srhines, kubamracek, mgorny, hiraditya, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D52249
llvm-svn: 342921
Summary:
The complex division builtins (div?c3) use logb methods from libm to scale numbers during division and avoid rounding issues. However, these come from libm, meaning anyone that uses --rtlib=compiler-rt also has to include -lm. Implement logb* methods for standard ieee 754 floats so we can avoid -lm on those platforms, falling back to the old behavior (using either logb() or `__builtin_logb()`) when not supported.
These new methods are defined internally as `__compiler_rt_logb` so as not to conflict with the libm definitions in any way.
This fixes just the libm methods mentioned in PR32279 and PR28652. libc is still required, although that seems to not be an issue.
Note: this is proposed as an alternative to just adding -lm: D49330.
Reviewers: efriedma, compnerd, scanon, echristo
Reviewed By: echristo
Subscribers: jsji, echristo, nemanjai, dberris, mgorny, kbarton, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49514
llvm-svn: 342917
Summary:
Previously we'd just show the exception and not the output from the
executed script. This is unhelpful in the case that the script actually
reports some useful information on the failure.
Now we print the output and re-raise the exception.
Reviewers: kubamracek, george.karpenkov
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D52350
llvm-svn: 342869
changing the value of `SANITIZER_MMAP_RANGE_SIZE` to something more
sensible. The available VMA is at most 64GiB and not 256TiB that
was previously being used.
This change gives us several wins:
* Drastically improves LeakSanitizer performance on
Darwin ARM64 devices. On a simple synthentic benchmark
this took leak detection time from ~30 seconds to 0.5 seconds
due to the `ForEachChunk(...)` method enumerating a much smaller
number of regions. Previously we would pointlessly iterate
over a large portion of the SizeClassAllocator32's ByteMap
that would could never be set due it being configured for a much
larger VM space than is actually availble.
* Decreases the memory required for the Primary allocator.
Previously the ByteMap inside the the allocator used
an array of pointers that took 512KiB of space. Now the required
space for the array is 128 bytes.
rdar://problem/43509428
Differential Revision: https://reviews.llvm.org/D51173
llvm-svn: 342868
Summary:
This change spans both LLVM and compiler-rt, where we do the following:
- Add XRay to the LLVMBuild system, to allow for distributing the XRay
trace loading library along with the LLVM distributions.
- Use `llvm-config` better in the compiler-rt XRay implementation, to
depend on the potentially already-distributed LLVM XRay library.
While this is tested with the standalone compiler-rt build, it does
require that the LLVMXRay library (and LLVMSupport as well) are
available during the build. In case the static libraries are available,
the unit tests will build and work fine. We're still having issues with
attempting to use a shared library version of the LLVMXRay library since
the shared library might not be accessible from the standard shared
library lookup paths.
The larger change here is the inclusion of the LLVMXRay library in the
distribution, which allows for building tools around the XRay traces and
profiles that the XRay runtime already generates.
Reviewers: echristo, beanz
Subscribers: mgorny, hiraditya, mboerger, llvm-commits
Differential Revision: https://reviews.llvm.org/D52349
llvm-svn: 342859
Summary:
pthread_join() can return before a thread finishes exit()ing in the
kernel and a subsequent tgkill() can report the thread still alive.
Update the pthread-cleanup.c test to sleep and retry if it hits this
possible flake.
Thanks to Jeremy Morse for reporting.
Reviewers: jmorse, eugenis, vitalybuka
Reviewed By: jmorse, vitalybuka
Subscribers: delcypher, jfb, llvm-commits, #sanitizers, kcc
Differential Revision: https://reviews.llvm.org/D52330
llvm-svn: 342763
Summary:
`__sanitizer_set_death_callback` is a public interface function wrapping
`SetUserDieCallback`. Said function is defined in `sanitizer_termination.cc`,
which is not included in all the RT. Moving the interface function to that
file allows to not have a spurious public fuinction in RT that don't use it.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D52363
llvm-svn: 342747
Summary:
The implementation of `internal_mmap(...)` deviates from the contract of
`mmap(...)` -- i.e. error returns are actually the equivalent of `errno`
results. We update how XRay uses `internal_mmap(...)` to better handle
these error conditions.
In the process, we change the default pointers we're using from `char*`
to `uint8_t*` to prevent potential usage of the pointers in the string
library functions that expect to operate on `char*`.
We also take the chance to "promote" sizes of individual `internal_mmap`
requests to at least page size bytes, consistent with the expectations
of calls to `mmap`.
Reviewers: cryptoad, mboerger
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D52361
llvm-svn: 342745
r342698 removed the 'UNSUPPORTED: windows' flags from a number of fuzzer
tests, however too many lines were removed from 'fuzzer-flags.test',
including the run-line that generates the test binary, which breaks that
test for me (and the clang-x64-ninja-win7 buildbot). This patch just
re-adds that line.
llvm-svn: 342720
Summary:
The goal of D49916 is to remove some hit counters from lines like '}'.
So as a consequence, the tests must be fixed.
FYI, after holidays, I'll add more tests.
Reviewers: marco-c, davidxl
Reviewed By: marco-c
Subscribers: delcypher, llvm-commits, #sanitizers, sylvestre.ledru
Differential Revision: https://reviews.llvm.org/D49917
llvm-svn: 342718
Summary:
Replace FuzzerExtFunctionsDlsymWin.cpp with FuzzerExtFunctionsWeakAlias.cpp
to get externally defined functions (eg: LLVMFuzzerInitialize,
LLVMFuzzerCustomMutator, etc) working again.
Also enable tests that depended on these functions (on windows)
Reviewers: rnk, morehouse
Reviewed By: rnk, morehouse
Subscribers: rnk, morehouse, mgorny
Differential Revision: https://reviews.llvm.org/D51700
llvm-svn: 342698
Summary: Some tests are broken if patch in D49659 is accepted so this patch fixes them.
Reviewers: marco-c
Reviewed By: marco-c
Subscribers: dberris, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49721
llvm-svn: 342661
In long-running builds we've seen some ASan complaints during thread creation that we suspect are due to leftover poisoning from previous threads whose stacks occupied that memory. This patch adds a hook that unpoisons the stack just before the NtTerminateThread syscall.
Differential Revision: https://reviews.llvm.org/D52091
llvm-svn: 342652
Summary:
As far as I can tell, there is no reason why `__sanitizer::CheckFailed` should
be exported. Looking back in time, it was added with the FIXME with the
following by @timurrrr:
```
[*San/RTL] Fix minor breakage
Grumbling: this hasn't been caught by running 'make check-{a,l,t}san check-sanitizer'
```
I can't find any detail about the breakage, all tests seem to work for me, so
maybe Windows (@rnk?) or something I have no setup for.
The reason to make it private (past the FIXME) is that Scudo defines its own
(without callback) and I am trying to make the .so be loadable with the UBsan
one (that has its own public `CheckFailed`) with as little drama as possible.
Reviewers: eugenis, rnk
Reviewed By: eugenis, rnk
Subscribers: kubamracek, delcypher, #sanitizers, timurrrr, rnk, llvm-commits
Differential Revision: https://reviews.llvm.org/D52279
llvm-svn: 342651
Same idea as r310419: The 8 byte nop is a suffix of the 9 byte nop, and we need at most 6 bytes.
Differential Revision: https://reviews.llvm.org/D51788
llvm-svn: 342649
Summary:
This change introduces an `FDRLogWriter` type which is responsible for
serialising metadata and function records to character buffers. This is
the first step in a refactoring of the implementation of the FDR runtime
to allow for more granular testing of the individual components of the
implementation.
The main contribution of this change is a means of hiding the details of
how specific records are written to a buffer, and for managing the
extents of these buffers. We make use of C++ features (templates and
some metaprogramming) to reduce repetition in the act of writing out
specific kinds of records to the buffer.
In this process, we make a number of changes across both LLVM and
compiler-rt to allow us to use the `Trace` abstraction defined in the
LLVM project in the testing of the runtime implementation. This gives us
a closer end-to-end test which version-locks the runtime implementation
with the loading implementation in LLVM.
We also allow using gmock in compiler-rt unit tests, by adding the
requisite definitions in the `AddCompilerRT.cmake` module. We also add
the terminfo library detection along with inclusion of the appropriate
compiler flags for header include lookup.
Finally, we've gone ahead and updated the FDR logging implementation to
use the FDRLogWriter for the lowest-level record-writing details.
Following patches will isolate the state machine transitions which
manage the set-up and tear-down of the buffers we're using in multiple
threads.
Reviewers: mboerger, eizan
Subscribers: mgorny, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D52220
llvm-svn: 342617
This is called by Bionic on dlclose to delete the emutls pthread key.
The return value of pthread_key_delete is unchecked and behaviour of
multiple calls to the method is dependent on the implementation of
pthread_key_delete.
Differential Revision: https://reviews.llvm.org/D52251
llvm-svn: 342608
Summary:
Destroy and close a range's vmar if all its memory was unmapped.
This addresses some performance regression due to the proliferation of vmars
when Secondary backed allocations are concerned with Scudo on Fuchsia.
When a Secondary backed allocation was freed, the associated
`ReservedAddressRange` was going away after unmapping the entirety of the
mapping, but without getting rid of the associated vmar properly (which
was created specifically for that mapping). This resulted in an increase of
defunct vmars, that in turn slowed down further new vmar allocations.
This appears to solve ZX-2560/ZX-2642, at least on QEMU.
Reviewers: flowerhack, mcgrathr, phosek, mseaborn
Reviewed By: mcgrathr
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D52242
llvm-svn: 342584
of a darwin platform was in the list of `UBSAN_SUPPORTED_ARCH`.
This is a follow up to r341306.
The typo meant that if an architecture was a prefix to another
architecture in the list (e.g. `armv7` is a prefix of `armv7k`) then
this would trigger a match which is not the intended behaviour.
rdar://problem/41126835
llvm-svn: 342553
Summary:
This patch adds TSan runtime support for Go on linux-aarch64
platforms. This enables people working on golang to implement their
platform/language part of the TSan support.
Basic testing is done with lib/tsan/go/buildgo.sh. Additional testing will be
done as part of the work done in the Go project.
It is intended to support other VMA sizes, except 39 which does not
have enough bits to support the Go heap requirements.
Patch by Fangming Fang <Fangming.Fang@arm.com>.
Reviewers: kubamracek, dvyukov, javed.absar
Subscribers: mcrosier, dberris, mgorny, kristof.beyls, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D52167
llvm-svn: 342541
Instead of assuming `-ltinfo` works, check whether there's terminfo
support on the host where LLVMSupport is compiled.
Follow-up to D52220.
llvm-svn: 342523
Summary:
This change introduces an `FDRLogWriter` type which is responsible for
serialising metadata and function records to character buffers. This is
the first step in a refactoring of the implementation of the FDR runtime
to allow for more granular testing of the individual components of the
implementation.
The main contribution of this change is a means of hiding the details of
how specific records are written to a buffer, and for managing the
extents of these buffers. We make use of C++ features (templates and
some metaprogramming) to reduce repetition in the act of writing out
specific kinds of records to the buffer.
In this process, we make a number of changes across both LLVM and
compiler-rt to allow us to use the `Trace` abstraction defined in the
LLVM project in the testing of the runtime implementation. This gives us
a closer end-to-end test which version-locks the runtime implementation
with the loading implementation in LLVM.
We also allow using gmock in compiler-rt unit tests, by adding the
requisite definitions in the `AddCompilerRT.cmake` module.
Finally, we've gone ahead and updated the FDR logging implementation to
use the FDRLogWriter for the lowest-level record-writing details.
Following patches will isolate the state machine transitions which
manage the set-up and tear-down of the buffers we're using in multiple
threads.
Reviewers: mboerger, eizan
Subscribers: mgorny, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D52220
llvm-svn: 342518
The CMAKE_<LANG>_ARCHIVE_FINISH rule doesn't need to be cleared for Darwin
static libraries. Avoid resetting the variables in the SIP case. If
CMAKE_RANLIB is cached, then CMake's Ninja generator will invoke ranlib during
installation, not due to the CMAKE_<LANG>_ARCHIVE_FINISH rule.
llvm-svn: 342511
On sparc64/Linux, sparc64 isn't defined; the canonical way of
checking for sparc64 is sparc && arch64, which also works on the
BSDs and Solaris. Since this problem does not occur on 32-bit
architectures, riscv32 can be ignored. This fixes and refines rL324593.
Patch by jrtc27 (James Clarke)
Differential Revision: https://reviews.llvm.org/D43146
llvm-svn: 342504
When building static fat libraries, we need to ensure that we use libtool rather
than llvm-ar to create the library. Duplicate the rules from LLVM to ensure
that we correctly build the fat libraries when building compiler-rt standalone.
This also requires that we duplicate the workaround for the `DYLD_LIBRARY_PATH`
for SIP. Additionally, ensure that we set the `CMAKE_*_ARCHIVE_FINISH` variable
to ensure that we do not try to use `ranlib` on that target.
llvm-svn: 342425
Summary:
In order for this test to work the log file needs to be removed from both
from the host and device. To fix this the `rm` `RUN` lines have been
replaced with `RUN: rm` followed by `RUN: %device_rm`.
Initially I tried having it so that `RUN: %run rm` implicitly runs `rm`
on the host as well so that only one `RUN` line is needed. This
simplified writing the test however that had two large drawbacks.
* It's potentially very confusing (e.g. for use of the device scripts outside
of the lit tests) if asking for `rm` to run on device also causes files
on the host to be deleted.
* This doesn't work well with the glob patterns used in the test.
The host shell expands the `%t.log.*` glob pattern and not on the
device so we could easily miss deleting old log files from previous
test runs if the corresponding file doesn't exist on the host.
So instead deletion of files on the device and host are explicitly
separate commands.
The command to delete files from a device is provided by a new
substitution `%device_rm` as suggested by Filipe Cabecinhas.
The semantics of `%device_rm` are that:
* It provides a way remove files from a target device when
the host is not the same as the target. In the case that the
host and target are the same it is a no-op.
* It interprets shell glob patterns in the context of the device
file system instead of the host file system.
This solves the globbing problem provided the argument is quoted so
that lit's underlying shell doesn't try to expand the glob pattern.
* It supports the `-r` and `-f` flags of the `rm` command,
with the same semantics.
Right now an implementation of `%device_rm` is provided only for
ios devices. For all other devices a lit warning is emitted and
the `%device_rm` is treated as a no-op. This done to avoid changing
the behaviour for other device types but leaves room for others
to implement `%device_rm`.
The ios device implementation uses the `%run` wrapper to do the work
of removing files on a device.
The `iossim_run.py` script has been fixed so that it just runs `rm`
on the host operating system because the device and host file system
are the same.
rdar://problem/41126835
Reviewers: vsk, kubamracek, george.karpenkov, eugenis
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D51648
llvm-svn: 342391
Support for .preinit_array has been implemented in Fuchsia's libc,
add Fuchsia to the list of platforms that support this feature.
Differential Revision: https://reviews.llvm.org/D52155
llvm-svn: 342357
Summary:
This change makes XRay FDR mode use a single backing store for the
buffer queue, and have indexes into that backing store instead. We also
remove the reliance on the internal allocator implementation in the FDR
mode logging implementation.
In the process of making this change we found an inconsistency with the
way we're returning buffers to the queue, and how we're setting the
extents. We take the chance to simplify the way we're managing the
extents of each buffer. It turns out we do not need the indirection for
the extents, so we co-host the atomic 64-bit int with the buffer object.
It also seems that we've not been returning the buffers for the thread
running the flush functionality when writing out the files, so we can
run into a situation where we could be missing data.
We consolidate all the allocation routines now into xray_allocator.h,
where we used to have routines defined in xray_buffer_queue.cc.
Reviewers: mboerger, eizan
Subscribers: jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D52077
llvm-svn: 342356
This API has been deprecated three months ago and shouldn't be used
anymore, all clients should migrate to the new string based API.
Differential Revision: https://reviews.llvm.org/D51606
llvm-svn: 342318
Since we changed our inlining parameters, this test case was failing
on SystemZ, as the two tests were now both inlined into the main
function, which the test didn't expect. Fixed by adding a few more
noinline attributes.
llvm-svn: 342236
Summary:
Before this change, we only emit the XRay attributes in LLVM IR when the
-fxray-instrument flag is provided. This may cause issues with thinlto
when the final binary is being built/linked with -fxray-instrument, and
the constitutent LLVM IR gets re-lowered with xray instrumentation.
With this change, we can honour the "never-instrument "attributes
provided in the source code and preserve those in the IR. This way, even
in thinlto builds, we retain the attributes which say whether functions
should never be XRay instrumented.
This change addresses llvm.org/PR38922.
Reviewers: mboerger, eizan
Subscribers: mehdi_amini, dexonsmith, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D52015
llvm-svn: 342200
Summary:
This change has a number of fixes for FDR mode in compiler-rt along with
changes to the tooling handling the traces in llvm.
In the runtime, we do the following:
- Advance the "last record" pointer appropriately when writing the
custom event data in the log.
- Add XRAY_NEVER_INSTRUMENT in the rewinding routine.
- When collecting the argument of functions appropriately marked, we
should not attempt to rewind them (and reset the counts of functions
that can be re-wound).
In the tooling, we do the following:
- Remove the state logic in BlockIndexer and instead rely on the
presence/absence of records to indicate blocks.
- Move the verifier into a loop associated with each block.
Reviewers: mboerger, eizan
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D51965
llvm-svn: 342122
Similarly to before, D51985 again reduced the number of registers
required for the read/write routines causing this test to fail on
sanitizer-x86_64-linux-autoconf.
llvm-svn: 342092
This fixes building on a case sensitive filesystem with mingw-w64
headers, where all headers are lowercase, and matches how these
headers are included elsewhere in compiler-rt.
Also include these headers with angle brackets, as they are system
headers.
Differential Revision: https://reviews.llvm.org/D51913
llvm-svn: 341983
Right now, the counters are added in regards of the number of successors
for a given BasicBlock: it's good when we've only 1 or 2 successors (at
least with BranchInstr). But in the case of a switch statement, the
BasicBlock after switch has several predecessors and we need know from
which BB we're coming from.
So the idea is to revert what we're doing: add a PHINode in each block
which will select the counter according to the incoming BB. They're
several pros for doing that:
- we fix the "switch" bug
- we remove the function call to "__llvm_gcov_indirect_counter_increment"
and the lookup table stuff
- we replace by PHINodes, so the optimizer will probably makes a better
job.
Patch by calixte!
Differential Revision: https://reviews.llvm.org/D51619
llvm-svn: 341977
This function isn't declared with a const parameter anywhere; neither
in MSVC (neither in ucrt or in older msvcrt versions) nor in mingw-w64.
Differential Revision: https://reviews.llvm.org/D51876
llvm-svn: 341903
This fixes building on a case sensitive filesystem with mingw-w64
headers, where all headers are lowercase. This header actually also
is named with a lowercase name in the Windows SDK as well.
Differential Revision: https://reviews.llvm.org/D51877
llvm-svn: 341857
Summary:
In this change we apply `XRAY_NEVER_INSTRUMENT` to more functions in the
profiling implementation to ensure that these never get instrumented if
the compiler used to build the library is capable of doing XRay
instrumentation.
We also consolidate all the allocators into a single header
(xray_allocator.h) which sidestep the use of the internal allocator
implementation in sanitizer_common.
This addresses more cases mentioned in llvm.org/PR38577.
Reviewers: mboerger, eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D51776
llvm-svn: 341647
Summary:
Enables trace-malloc-unbalanced.test on Windows, fixing two problems it had with Windows before.
The first fix is specifying python instead of relying on a script's shebang since they can't be used on Windows.
The second fix is making the regex tolerate windows' implementation of the "%p" format string.
Reviewers: Dor1s
Reviewed By: Dor1s
Subscribers: morehouse
Differential Revision: https://reviews.llvm.org/D51760
llvm-svn: 341632
Summary:
When targeting MSVC: compile using clang's cl driver mode (this is needed for
libfuzzer's exit_on_src_pos feature). Don't use -lstdc++ when linking,
it isn't needed and causes a warning.
On Windows: Fix exit_on_src_pos.test by making sure debug info isn't
overwritten during compilation of second binary by using .exe extension.
Reviewers: morehouse
Reviewed By: morehouse
Subscribers: aprantl, JDevlieghere
Differential Revision: https://reviews.llvm.org/D51757
llvm-svn: 341622
Summary:
When building without COMPILER_RT_HWASAN_WITH_INTERCEPTORS, skip
interceptors for malloc/free/etc and only export their versions with
__sanitizer_ prefix.
Also remove a hack in mallinfo() interceptor that does not apply to
hwasan.
Reviewers: kcc
Subscribers: kubamracek, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D51711
llvm-svn: 341598
Add the __msan_va_arg_origin_tls TLS array to keep the origins for variadic function parameters.
Change the instrumentation pass to store parameter origins in this array.
This is a reland of r341528.
test/msan/vararg.cc doesn't work on Mips, PPC and AArch64 (because this
patch doesn't touch them), XFAIL these arches.
Also turned out Clang crashed on i80 vararg arguments because of
incorrect origin type returned by getOriginPtrForVAArgument() - fixed it
and added a test.
llvm-svn: 341554
MachO symbols are prefixed with an extra '_' (that's 3 in total for this
function), so assembly calls have to go through a wrapper to insert any prefix
needed.
llvm-svn: 341540
Add the __msan_va_arg_origin_tls TLS array to keep the origins for
variadic function parameters.
Change the instrumentation pass to store parameter origins in this array.
llvm-svn: 341528
Sigtrap is used for error reporting, but all other signals are better
left for the platform.
In particular, sanitizer signal handlers do not dump registers or
memory which makes debugging harder for no good reason.
llvm-svn: 341500
Summary:
Remove unneeded #include of <unistd.h> from SymbolizeDeadlock.cpp to
enable compilation on Windows and enable symbolize-deadlock.test on
Windows.
Patch by Jonathan Metzman (@metzman).
Reviewers: Dor1s
Reviewed By: Dor1s
Subscribers: kcc, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D51685
llvm-svn: 341473
Summary:
Enable tests on Windows and make check-fuzzer pass on it. Make
check-fuzzer pass on Windows by fixing libFuzzer, fixing tests, and by
disabling tests on Windows. Most of these are disabled temporarily as
support for the tests and the features they test will be added
incrementally. Other tests will not be enabled since they require
things that are not on Windows (eg: afl_driver tests). Every test
that was explicitly disabled on Windows has a comment explaining why
(unless obvious like merge-posix.test).
The lit.cfg file was modified to support running tests on windows.
fuzzer-dirs.test was fixed by making the Windows implementation print
the same error message as the posix version.
merge-control-file.test was fixed by making the test binary end with
the ".exe" extension (on all platforms).
Patch By: metzman
Reviewers: morehouse
Reviewed By: morehouse
Subscribers: srhines, mgorny
Differential Revision: https://reviews.llvm.org/D51549
llvm-svn: 341385
`test/asan/TestCases/Darwin/segv_read_write.c`
* The `fd` arg passed to `mmap()` should be `-1`. It is not defined
what passing `0` does on Darwin.
* The comment about the shadow memory doesn't make any sense to me,
so I'm removing it.
Differential Revision: https://reviews.llvm.org/D44579
llvm-svn: 341307
tests for ios, watchos, tvos, and their simulator counterparts.
This commit does not make the tests actually pass. This will be handled
in later commits.
rdar://problem/41126835
Differential Revision: https://reviews.llvm.org/D51270
llvm-svn: 341306
Summary: Give a better error message when trying to run the iossim tests and `SANITIZER_IOSSIM_TEST_DEVICE_IDENTIFIER` is not set in the environment.
Reviewers: kubamracek, george.karpenkov
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D51272
llvm-svn: 341300
sysctl has a different signature under OpenBSD
Reviewers: krytarowski
Reviewed By: krytarowski
Differential Revision: https://reviews.llvm.org/D51572
llvm-svn: 341285
Summary:
Switch local sysctl(2) calls to internal_sysctl().
This is a preparation for introduction of interceptors for
the sysctl*() family of functions and switching `internal_sysctl*()`
to libc calls bypassing interceptors.
No functional change intended with this revision.
Reviewers: vitalybuka, joerg, kcc
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D51425
llvm-svn: 341181
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Patch By: metzman
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
llvm-svn: 341082
using sysctl to get the tic frequency data.
still linkage issue for X-ray_init not resolved.
Reviewers: dberris, kubamracek
Reviewed By: dberris
Differential Revision: https://reviews.llvm.org/D51399
llvm-svn: 341019
Now that all _zx_vmar_... calls have been updated, we can undo the
change made in r337801 and switch over to the new calls.
Differential Revision: https://reviews.llvm.org/D51468
llvm-svn: 341011
Summary:
This was an experimental feature. After evaluating it with:
1) https://github.com/google/fuzzer-test-suite/tree/master/engine-comparison
2) enabling on real world fuzz targets running at ClusterFuzz and OSS-Fuzz
The following conclusions were made:
1) With fuzz targets that have reached a code coverage plateau, the feature does
not improve libFuzzer's ability to discover new coverage and may actually
negatively impact it.
2) With fuzz targets that have not yet reached a code coverage plateau, the
feature might speed up new units discovery in some cases, but it is quite
rare and hard to confirm with a high level on confidence.
Revert of https://reviews.llvm.org/D48054 and https://reviews.llvm.org/D49621.
Reviewers: metzman, morehouse
Reviewed By: metzman, morehouse
Subscribers: delcypher, #sanitizers, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D51455
llvm-svn: 340976
Summary:
We need this in order to properly report heap-use-after-free,
since we don't have a quarantine.
This is a first part of the code, more like a proof of concept.
But I'd like to commit at as is and proceed with refactoring,
adding a ThreadRegistry, and extending the functionality.
Reviewers: eugenis
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D51394
llvm-svn: 340971
Summary:
The previous version of the patch makes some code unable to distinguish
failure to map address 0 and error.
Revert to turn the bots back to green while figuring out a new approach.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D51451
llvm-svn: 340957
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
llvm-svn: 340949
The test doesn't pass on Windows, where sizeof(long) == 4 also
on 64-bit, and so it isn't a multiple of sizeof(void*).
This also reverts the follow-up r340886.
> Summary: a constrained RingBuffer optimized for fast push
>
> Reviewers: eugenis
>
> Reviewed By: eugenis
>
> Subscribers: kubamracek, mgorny, delcypher, #sanitizers, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D51196
llvm-svn: 340924
Summary:
The UINTMAX_T type will be used in new interceptors.
While there, correct the type of strtoumax(3) from INTMAX_T to UINTMAX_T.
Original patch from Yang Zheng.
Reviewers: vitalybuka, kcc, joerg
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, tomsun.0.7, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D51106
llvm-svn: 340907
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Patch By: metzman
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
llvm-svn: 340860
Summary:
This change removes further cases where the profiling mode
implementation relied on dynamic memory allocation. We're using
thread-local aligned (uninitialized) memory instead, which we initialize
appropriately with placement new.
Addresses llvm.org/PR38577.
Reviewers: eizan, kpw
Subscribers: jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D51278
llvm-svn: 340814
Summary:
This change saves and restores the full flags register in x86_64 mode.
This makes running instrumented signal handlers safer, and avoids flags
set during the execution of the event handlers from polluting the
instrumented call's flags state.
Reviewers: kpw, eizan, jfb
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D51277
llvm-svn: 340812
Now that all Zircon calls have been transitioned to take time as signed
value, we can transition back to ZX_TIME_INFINITE, undoing the change
made in r337802.
Differential Revision: https://reviews.llvm.org/D51266
llvm-svn: 340764
Summary:
The reason for the existence of `eraseHeader` was that it was deemed faster
to null-out a chunk header, effectively making it invalid, rather than marking
it as available, which incurred a checksum computation and a cmpxchg.
A previous use of `eraseHeader` was removed with D50655 due to a race.
Now we remove the second use of it in the Quarantine deallocation path and
replace is with a `compareExchangeHeader`.
The reason for this is that greatly helps debugging some heap bugs as the chunk
header is now valid and the chunk marked available, as opposed to the header
being invalid. Eg: we get an invalid state error, instead of an invalid header
error, which reduces the possibilities. The computational penalty is negligible.
Reviewers: alekseyshl, flowerhack, eugenis
Reviewed By: eugenis
Subscribers: delcypher, jfb, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D51224
llvm-svn: 340633
- GetRandom and GetnumberOfCPUs using sys call for the former.
- enabling unit tests for the other oses.
Reviewers: kubamracek
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D50937
llvm-svn: 340621
Calling task_for_pid with mach_task_self is just returning mach_task_self anyway, but it also triggers system warnings (task_for_pid is only supposed to be used by high-privileged executables). NFC.
rdar://problem/39198248
Differential Revision: https://reviews.llvm.org/D51119
llvm-svn: 340587
Summary:
`MmapNoAccess` & `MmapFixedNoAccess` return directly the result of
`internal_mmap`, as opposed to other Mmap functions that return nullptr.
This inconsistency leads to some confusion for the callers, as some check for
`~(uptr)0` (`MAP_FAILED`) for failure (while it can fail with `-ENOMEM` for
example).
Two potential solutions: change the callers, or make the functions return
`nullptr` on failure to follow the precedent set by the other functions.
The second option looked more appropriate to me.
Correct the callers that were wrongly checking for `~(uptr)0` or
`MAP_FAILED`.
TODO for follow up CLs:
- There are a couple of `internal_mmap` calls in XRay that check for
MMAP_FAILED as a result as well (cc: @dberris); they should use
`internal_iserror`;
Reviewers: eugenis, alekseyshl, dberris, kubamracek
Reviewed By: alekseyshl
Subscribers: kristina, kubamracek, delcypher, #sanitizers, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D50940
llvm-svn: 340576
On macOS Mojave, the OS started using the XOR-by-a-secret-key scheme (same as glibc is alread doing) for storing the SP value in setjmp environment. We need to adjust for that to keep supporting setjmp/longjmp on latest Darwin. The patch is basically doing the same what we're already doing for glibc.
rdar://problem/43542596
Differential Revision: https://reviews.llvm.org/D51064
llvm-svn: 340350
The synchronous dispatch functions in GCD (dispatch_sync, dispatch_barrier_sync), don't make a copy of the passed block. To maintain binary compatibility, we should avoid doing that as well in TSan, as there's no reason to do that. The synchronous dispatch functions will not return before the block is actually executed.
rdar://problem/42242579
Differential Revision: https://reviews.llvm.org/D50920
llvm-svn: 340342
Summary:
When deallocating thread stacks, we use one thread's unsafe stack size
to deallocate another thread's unsafe stack; however, the two sizes may
differ. Record an unsafe stack's size in the thread stack linked list.
Reviewers: pcc, eugenis
Reviewed By: eugenis
Subscribers: delcypher, llvm-commits, #sanitizers, kcc
Differential Revision: https://reviews.llvm.org/D51016
llvm-svn: 340308
Summary:
The idea behind this change is to allow sanitization of libc. We are prototyping on Bionic,
but the tool interface will be general enough (or at least generalizable) to support any other libc.
When libc depends on libclang_rt.hwasan, the latter can not interpose libc functions.
In fact, majority of interceptors become unnecessary when libc code is instrumented.
This change gets rid of most hwasan interceptors and provides interface for libc to notify
hwasan about thread creation and destruction events. Some interceptors (pthread_create)
are kept under #ifdef to enable testing with uninstrumented libc. They are expressed in
terms of the new libc interface.
The new cmake switch, COMPILER_RT_HWASAN_WITH_INTERCEPTORS, ON by default, builds testing
version of the library with the aforementioned pthread_create interceptor.
With the OFF setting, the library becomes more of a libc plugin.
Reviewers: vitalybuka, kcc, jfb
Subscribers: srhines, kubamracek, mgorny, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D50922
llvm-svn: 340216
Summary:
Use `FUTEX_PRIVATE_FLAG` in conjunction with the wait & wake operations
employed by `BlockingMutex`. As far as I can tell, the mutexes are
process-private, and there is an actual performance benefit at employing the
private operations. There should be no downside to switching to it.
Reviewers: eugenis, alekseyshl, dvyukov
Reviewed By: dvyukov
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D50910
llvm-svn: 340178
task_vm_info is a "revisioned" structure, new OS versions add fields to the end, and compatibility is based on the reported size. On older OS versions, min_address/max_address is not filled back. Let's handle that case. Unfortunately, we can't really write a test (as the failure only happens when on a specific OS version).
Differential Revision: https://reviews.llvm.org/D50275
llvm-svn: 340058
Summary:
We avoid using dynamic memory allocated with the internal allocator in
the profile collection service used by profiling mode. We use aligned
storage for globals and in-struct storage of objects we dynamically
initialize.
We also remove the dependency on `Vector<...>` which also internally
uses the dynamic allocator in sanitizer_common (InternalAlloc) in favour
of the XRay allocator and segmented array implementation.
This change addresses llvm.org/PR38577.
Reviewers: eizan
Reviewed By: eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50782
llvm-svn: 339978
Summary:
Since we're casting from double to size_t during input selection, we
really want a discrete distribution over size_t rather than a piecewise
distribution over doubles.
Reviewers: kcc
Reviewed By: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50356
llvm-svn: 339973
This reapplies commit r339935 with the following changes:
* make longjmp test C, not C++, to avoid dependency on libc++/libstdc++
* untag pointer in memset interceptor
x86_64 does not have TBI, so hwasan barely works there. Tests must be carefully
written in a way that does not leak tagged pointer to system libraries.
llvm-svn: 339963
Summary:
A callback to annotate longjmp-like code.
Unlike __asan_handle_no_return, in hwasan we can not conservatively
"unpoison" the entire thread stack, because there is no such thing as
unpoisoned memory. Pointer and memory tags must always match.
Reviewers: vitalybuka, kcc
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D50752
llvm-svn: 339935
- The alternative syscall exists only on FreeBSD.
- Adding OpenBSD's equivalent and while at it other
remaining oses ones.
Reviewers: vitalybuka, krytarowsky, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D50760
llvm-svn: 339886
Summary:
This reverses an earlier decision to allow seg-faulting from the
XRay-allocated memory if it turns out that the system cannot provide
physical memory backing that cannot be swapped in/out on Linux.
This addresses http://llvm.org/PR38588.
Reviewers: eizan
Reviewed By: eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50831
llvm-svn: 339869
Summary:
Without this metadata LLD strips unused PC table entries
but won't strip unused guards. This metadata also seems
to influence the linker to change the ordering in the PC
guard section to match that of the PC table section.
The libFuzzer runtime library depends on the ordering
of the PC table and PC guard sections being the same. This
is not generally guaranteed, so we may need to redesign
PC tables/guards/counters in the future.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: kcc, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D50483
llvm-svn: 339733
This relands commit r339405 (reverted in commit r339408.) The original
revert was due to tests failing on a darwin buildbot; however, after
looking at the affected code more I realized that the Darwin safestack
support has always been broken and disabled it in r339719. This relands
the original commit.
llvm-svn: 339723
Summary:
Darwin support does not appear to be used as evidenced by the fact that
the pthread interceptors have never worked and there is no support for
other common threading mechanisms like GCD.
Reviewers: pcc, eugenis, kubamracek
Reviewed By: pcc, kubamracek
Subscribers: kubamracek, mgorny, delcypher, llvm-commits, #sanitizers, kcc
Differential Revision: https://reviews.llvm.org/D50718
llvm-svn: 339719
Summary:
There is a race window in the deallocation path when the Quarantine is bypassed.
Initially we would just erase the header of a chunk if we were not to use the
Quarantine, as opposed to using a compare-exchange primitive, to make things
faster.
It turned out to be a poor decision, as 2 threads (or more) could simultaneously
deallocate the same pointer, and if the checks were to done before the header
got erased, this would result in the pointer being added twice (or more) to
distinct thread caches, and eventually be reused.
Winning the race is not trivial but can happen with enough control over the
allocation primitives. The repro added attempts to trigger the bug, with a
moderate success rate, but it should be enough to notice if the bug ever make
its way back into the code.
Since I am changing things in this file, there are 2 smaller changes tagging
along, marking a variable `const`, and improving the Quarantine bypass test at
runtime.
Reviewers: alekseyshl, eugenis, kcc, vitalybuka
Reviewed By: eugenis, vitalybuka
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D50655
llvm-svn: 339705
compiler-rt CMake build currently tries to parse the triple and then
put it back together, but doing so inherently tricky, and doing so
from CMake is just crazy and currently doesn't handle triples that
have more than three components. Fortunatelly, the CMake really only
needs the architecture part, which is typically the first component,
to construct variants for other architectures. This means we can keep
the rest of the triple as is and avoid the parsing altogether.
Differential Revision: https://reviews.llvm.org/D50548
llvm-svn: 339701
Summary:
Export __sanitizer_malloc, etc as aliases to malloc, etc.
This way users can wrap sanitizer malloc, even in fully static binaries.
Both jemalloc and tcmalloc provide similar aliases (je_* and tc_*).
Reviewers: vitalybuka, kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D50570
llvm-svn: 339614
Summary:
Don't crash when /proc/self/maps is inaccessible from main thread.
It's not a big deal, really.
Reviewers: vitalybuka, kcc
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D50574
llvm-svn: 339607
Summary:
Provide __hwasan_shadow_init that can be used to initialize shadow w/o touching libc.
It can be used to bootstrap an unusual case of fully-static executable with
hwasan-instrumented libc, which needs to run hwasan code before it is ready to serve
user calls like madvise().
Reviewers: vitalybuka, kcc
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D50581
llvm-svn: 339606
Summary:
When compiling with `WERROR=ON` & a recent clang, having the `st(?)` registers
in the clobber list produces a fatal error (except `st(7)` for some reason):
```
.../sanitizer_common/sanitizer_atomic_clang_x86.h:98:9: error: inline asm clobber list contains reserved registers: ST0, ST1, ST2, ST3, ST4, ST5, ST6 [-Werror,-Winline-asm]
"movq %1, %%mm0;" // Use mmx reg for 64-bit atomic moves
^
<inline asm>:1:1: note: instantiated into assembly here
movq 8(%esp), %mm0;movq %mm0, (%esi);emms;
^
.../sanitizer_common/sanitizer_atomic_clang_x86.h:98:9: note: Reserved registers on the clobber list may not be preserved across the asm statement, and clobbering them may lead to undefined behaviour.
"movq %1, %%mm0;" // Use mmx reg for 64-bit atomic moves
^
<inline asm>:1:1: note: instantiated into assembly here
movq 8(%esp), %mm0;movq %mm0, (%esi);emms;
^
```
As far as I can tell, they were in there due to the use of the `emms`
instruction, but removing the clobber doesn't appear to have a functional
impact. I am unsure if there is a better way to address this.
Reviewers: eugenis, vitalybuka
Reviewed By: vitalybuka
Subscribers: kubamracek, delcypher, jfb, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D50562
llvm-svn: 339575
Previously the the `weak_symbols.txt` files could be modified and the
build system wouldn't update the link flags automatically. Instead the
developer had to know to reconfigure CMake manually.
This is now fixed by telling CMake that the file being used to
read weak symbols from is a configure-time dependency.
Differential Revision: https://reviews.llvm.org/D50059
llvm-svn: 339559
HWASan will not run on older Android releases where we use
__android_log_write for logging.
This dependency is also harmful in the case when libc itself depends
on hwasan, because it creates a loop of
libc -> hwasan -> liblog -> libc
which makes liblog vs libc initialization order undetermined.
Without liblog the loop is just
libc -> hwasan -> libc
and any init order issues can be solved in hwasan.
llvm-svn: 339449
This reverts commit r339405, it's failing on Darwin buildbots because
it doesn't seem to have a tgkill/thr_kill2 interface. It has a
__pthread_kill() syscall, but that relies on having a handle to the
thread's port which is not equivalent to it's tid.
llvm-svn: 339408
Summary:
glibc can call SafeStack instrumented code even after the last pthread
data destructor has run. Delay cleaning-up unsafe stacks for threads
until the thread is dead by having future threads clean-up prior threads
stacks.
Reviewers: pcc, eugenis
Reviewed By: eugenis
Subscribers: cryptoad, eugenis, kubamracek, delcypher, llvm-commits, #sanitizers, kcc
Differential Revision: https://reviews.llvm.org/D50406
llvm-svn: 339405
Summary:
When compiling with WERROR=ON, a new fatal warning started popping up recently
(due to -Werror,-Winline-asm):
```
.../lib/sanitizer_common/sanitizer_linux.cc:1214:24: error: inline asm clobber list contains reserved registers: RSP [-Werror,-Winline-asm]
"syscall\n"
^
<inline asm>:1:1: note: instantiated into assembly here
syscall
^
.../lib/sanitizer_common/sanitizer_linux.cc:1214:24: note: Reserved registers on the clobber list may not be preserved across the asm statement, and clobbering them may lead to undefined behaviour.
"syscall\n"
^
<inline asm>:1:1: note: instantiated into assembly here
syscall
^
```
Removing `rsp` from the clobber list makes the warning go away, and does not
appear to have a functional impact. If there is another way to solve this, let
me know.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D50519
llvm-svn: 339370
As for Linux with its getrandom's syscall, giving the possibility to fill buffer with native call for good quality but falling back to /dev/urandom in worst case similarly.
Reviewers: vitalybuka, krytarowski
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D48804
llvm-svn: 339318
Changes the default Windows target triple returned by
GetHostTriple.cmake from the old environment names (which we wanted to
move away from) to newer, normalized ones. This also requires updating
all tests to use the new systems names in constraints.
Differential Revision: https://reviews.llvm.org/D47381
llvm-svn: 339307
After https://reviews.llvm.org/D48800, shrink.test started failing on
x86_64h architecture.
Looking into this, the optimization pass is too eager to unroll the loop
on x86_64h, possibly leading to worse coverage data.
Alternative solutions include not unrolling the loop when fuzzing, or
disabling this test on that architecture.
Differential Revision: https://reviews.llvm.org/D50484
llvm-svn: 339303
Summary:
We only run the 3rd check if 2nd check finds unstable edges.
3rd UpdateUnstableCounters is now merged with ApplyUnstableCounters to only run 1 iteration.
Patch by Kyungtak Woo (@kevinwkt).
Reviewers: Dor1s, metzman, morehouse
Reviewed By: Dor1s, morehouse
Subscribers: delcypher, #sanitizers, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D50411
llvm-svn: 339249
Frontends emit 'unused' coverage mapping records for functions which are
provably unused in a TU. These unused records contain a single counter
with CounterKind::Zero. However, a function may be unused in one TU and
used in another. When this happens, prefer the records with a full set
of counters instead of arbitrarily picking the first loaded record.
There is no impact on the single-TU case. In the multiple-TU case, this
resolves issues causing a function to appear unused when it's not.
Testing: check-{llvm,clang,compiler-rt}
rdar://42981322
llvm-svn: 339194
Summary:
There may be cases in which a user wants to know which part of their code is unstable.
We use ObservedFuncs and UnstableCounters to print at exit which of the ObservedFunctions
are unstable under the -print_unstable_stats flag.
Patch by Kyungtak Woo (@kevinwkt).
Reviewers: Dor1s, metzman, morehouse
Reviewed By: Dor1s, metzman, morehouse
Subscribers: delcypher, #sanitizers, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D50264
llvm-svn: 339081
Summary:
Added functions that calculate stats while fuzz targets are running and give
mutations weight based on how much new coverage they provide, and choose better
performing mutations more often.
Patch by Kodé Williams (@kodewilliams).
Reviewers: Dor1s, metzman, morehouse
Reviewed By: Dor1s, morehouse
Subscribers: delcypher, kcc, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49621
llvm-svn: 338776
Summary:
This patch introduces `llvm_profile_set_dir_mode` and `llvm_profile_get_dir_mode` to
the compiler-rt profile API.
Originally, profile data was placed into a directory that was created with a hard-coded
mode value of 0755 (for non-win32 builds). In certain cases, it can be helpful to create
directories with a different mode other than 0755. This patch introduces set/get
routines to allow users to specify a desired mode. The default remains at 0755.
Reviewers: void, probinson
Reviewed By: probinson
Subscribers: probinson, dberris, cfe-commits
Differential Revision: https://reviews.llvm.org/D49953
llvm-svn: 338456
Summary:
This change provides access to the file header even in the in-memory
buffer processing. This allows in-memory processing of the buffers to
also check the version, and the format, of the profile data.
Reviewers: eizan, kpw
Reviewed By: eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50037
llvm-svn: 338347
Summary:
Before my change, BlockingMutex used Windows critial sections. Critical
sections can only be initialized by calling InitializeCriticalSection,
dynamically.
The primary sanitizer allocator expects to be able to reinterpret zero
initialized memory as a BlockingMutex and immediately lock it.
RegionInfo contains a mutex, and it placement new is never called for
it. These objects are accessed via:
RegionInfo *GetRegionInfo(uptr class_id) const {
DCHECK_LT(class_id, kNumClasses);
RegionInfo *regions = reinterpret_cast<RegionInfo *>(SpaceEnd());
return ®ions[class_id];
}
The memory comes from the OS without any other initialization.
For various reasons described in the comments, BlockingMutex::Lock would
check if the object appeared to be zero-initialized, and it would lazily
call the LinkerInitialized constructor to initialize the critical
section. This pattern is obviously racy, and the code had a bunch of
FIXMEs about it.
The best fix here is to use slim reader writer locks, which can start
out zero-initialized. They are available starting in Windows Vista. I
think it's safe to go ahead and use them today.
Reviewers: kcc, vitalybuka
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D49893
llvm-svn: 338331
Just to be consistent with the rest.
I should have done that in the commit itself, but the filepaths
is one thing i forgot to verify :S
llvm-svn: 338307
The Builder sanitizer-x86_64-linux-android is failing
starting with rL338287 / D48959.
It runs the tests via android_compile.py, so i'm not sure this
is actually *this* issue:
https://code.google.com/p/address-sanitizer/issues/detail?id=316
but this seems oddly similar to the other XFAIL'ed cases...
Right now that seems to be the only failing builder,
so i *think* it makes sense to try to just blacklist it for now.
llvm-svn: 338296
Summary:
rL325492 disables FPU features when using soft floating point
(-mfloat-abi=soft), which is used internally when building for arm. This causes
errors with builtins that utililize VFP instructions.
With this change we check if VFP is enabled (by checking if the preprocessor
macro __VFP_FP__ is defined), and exclude such builtins if it is not enabled.
Reviewers: rengolin, samsonov, compnerd, smeenai, javed.absar, peter.smith
Reviewed By: peter.smith
Subscribers: delcypher, peter.smith, mgorny, kristof.beyls, chrib, llvm-commits
Differential Revision: https://reviews.llvm.org/D47217
llvm-svn: 338284
Summary:
This change moves FDR mode to use `internal_mmap(...)` from
sanitizer_common instead of the internal allocator interface. We're
doing this to sidestep the alignment issues we encounter with the
`InternalAlloc(...)` functions returning pointers that have some magic
bytes at the beginning.
XRay copies bytes into the buffer memory, and does not require the magic
bytes tracking the other sanitizers use when allocating/deallocating
buffers.
Reviewers: kpw, eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49972
llvm-svn: 338228
0x22000000 happens to be on the left of a heap allocation and the error
message is different (heap-buffer-overflow).
FreeBSD NetBSD have larger SHADOW_OFFSET (0x40000000) but let's try not
using #ifdef here.
llvm-svn: 338208
This test fails with libc++ when built with MemorySanitizer. This
is because we link to an uninstrumented version of the library
so msan detects a nested error when calling std::cout << "...".
This can be easily avoided by using good old printf.
Differential Revision: https://reviews.llvm.org/D49867
llvm-svn: 338053
By default, xray filters events that takes less than 5uS from its log.
In this existing test, should printf complete very quickly this will
lead to test-critical function calls being filtered (i.e. print_parent_tid).
Given that we're not testing the filtering feature, disable it for this
test.
llvm-svn: 337929
David Carlier