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
This ports the profiling runtime on Fuchsia and enables the
instrumentation. Unlike on other platforms, Fuchsia doesn't use
files to dump the instrumentation data since on Fuchsia, filesystem
may not be accessible to the instrumented process. We instead use
the data sink to pass the profiling data to the system the same
sanitizer runtimes do.
Differential Revision: https://reviews.llvm.org/D47208
llvm-svn: 337881
Summary:
Added a new mode within flag -handle_unstable for new unstable handling algorithm that does the following:
When an edge is shown as unstable, copy to UnstableCounters the value 0.
During ApplyUnstableCounters we copy back the value 0 to ModuleInline8bitCounters if the edge was unstable.
This way we would be ignoring completely features that were collected through non-determinism.
Unstable hits would be counted as if it never hit.
Reviewers: metzman, Dor1s, kcc, morehouse
Reviewed By: metzman, morehouse
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49684
llvm-svn: 337853
Objective-C tagged pointers (either bottom-most or top-most bit is 1) are valid Obj-C objects but are not valid pointers. Make sure we don't crash on them when used in objc_sync_enter/objc_sync_exit. Instead, let's synchronize on a global object.
Differential Revision: https://reviews.llvm.org/D49707
llvm-svn: 337837
Until now, our code preferred backslashes to slashes, whereas Windows
allows using both types of directory separators in one path string.
Differential Revision: https://reviews.llvm.org/D49664
llvm-svn: 337826
This is a preparation for breaking change when all Zircon calls that
take time as an argument will start using signed valued. We will
transition back to ZX_TIME_INFITINE after all the changes to these
symbols are done and become part of the Fuchsia SDK.
Differential Revision: https://reviews.llvm.org/D49694
llvm-svn: 337802
This is a preparation for breaking changes to _zx_vmar_... calls.
We will transition back to _zx_vmar_... after all the changes to
these symbols are done and become part of the Fuchsia SDK.
Differential Revision: https://reviews.llvm.org/D49697
llvm-svn: 337801
The path to headers which are installed into libc++ build directory
has changed in r337727 which broke the libFuzzer build.
Differential Revision: https://reviews.llvm.org/D49705
llvm-svn: 337775
Summary:
Continuation of https://reviews.llvm.org/D49501
Second part of the test has an scheduling order when there shouldn't be.
Reviewers: dberris, ormris
Reviewed By: dberris, ormris
Subscribers: TWeaver
Differential Revision: https://reviews.llvm.org/D49559
llvm-svn: 337745
Summary:
Created unstable_handle flag that takes 1 or 2, depending on the handling type.
Modified RunOne to accommodate the following heuristic:
Use the first CollectFeatures to count how many features there are.
If no new features, CollectFeatures like before.
If there is new feature, we run CB 2 more times,
Check which edges are unstable per input and we store the least amount of hit counts for each edge.
Apply these hit counts back to inline8bitcounters so that CollectFeatures can work as intended.
Modified UnstableCounters to 8int_t and created a bitset UnstableSet to tell which edges are unstable.
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/D49525
llvm-svn: 337696
We tested different cap values with a recent commit of Chromium. Our results show that the 32-byte cap yields the smallest binary and all the caps yield similar performance.
Based on the results, we propose to change the cap value to 32-byte.
Patch by Zhaomo Yang!
Differential Revision: https://reviews.llvm.org/D49405
llvm-svn: 337622
When shadow stack from Intel CET is enabled, the first instruction of all
indirect branch targets must be a special instruction, ENDBR.
lib/asan/asan_interceptors.cc has
...
int res = REAL(swapcontext)(oucp, ucp);
...
REAL(swapcontext) is a function pointer to swapcontext in libc. Since
swapcontext may return via indirect branch on x86 when shadow stack is
enabled, as in this case,
int res = REAL(swapcontext)(oucp, ucp);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This function may be
returned via an indirect branch.
Here compiler must insert ENDBR after call, like
call *bar(%rip)
endbr64
I opened an LLVM bug:
https://bugs.llvm.org/show_bug.cgi?id=38207
to add the indirect_return attribute so that it can be used to inform
compiler to insert ENDBR after REAL(swapcontext) call. We mark
REAL(swapcontext) with the indirect_return attribute if it is available.
This fixed:
https://bugs.llvm.org/show_bug.cgi?id=38249
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D49608
llvm-svn: 337603
`VM_MEMORY_SANITIZER`.
It turns out that `VM_MEMORY_ANALYSIS_TOOL` is already reserved for
use by other tools so switch to a tag reserved for use by the Sanitizers.
rdar://problem/41969783
Differential Revision: https://reviews.llvm.org/D49603
llvm-svn: 337579
Summary:
There is currently too much redundancy in the class/variable/* names in Scudo:
- we are in the namespace `__scudo`, so there is no point in having something
named `ScudoX` to end up with a final name of `__scudo::ScudoX`;
- there are a lot of types/* that have `Allocator` in the name, given that
Scudo is an allocator I figure this doubles up as well.
So change a bunch of the Scudo names to make them shorter, less redundant, and
overall simpler. They should still be pretty self explaining (or at least it
looks so to me).
The TSD part will be done in another CL (eg `__scudo::ScudoTSD`).
Reviewers: alekseyshl, eugenis
Reviewed By: alekseyshl
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D49505
llvm-svn: 337557
r337531 changed return type of MmapFixedNoReserve, but esan wasn't updated.
As the result esan shadow setup always fails.
We probably need to make MmapFixedNoAccess signature consistent
with MmapFixedNoReserve. But this is just to unbreak tests.
llvm-svn: 337550
MmapFixedNoReserve does not terminate process on failure.
Failure to check its result and die will always lead to harder
to debug crashes later in execution. This was observed in Go
processes due to some address space conflicts.
Consistently check result of MmapFixedNoReserve.
While we are here also add warn_unused_result attribute
to prevent such bugs in future and change return type to bool
as that's what all callers want.
Reviewed in https://reviews.llvm.org/D49367
llvm-svn: 337531
Previously, check-all failed many tests for me. It was running the
X86_64DefaultLinuxConfig, X86_64LibcxxLinuxConfig, and
X86_64StaticLibcxxLinuxConfig configs out of
llvm-build/projects/compiler-rt/test/fuzzer. Now, it runs them out of
separate subdirectories there, and most tests pass.
Reviewed By: morehouse, george.karpenkov
Differential Revision: https://reviews.llvm.org/D49249
llvm-svn: 337521
Summary:
Add __llvm_profile_get_filename interface to get the profile filename,
which can be used for identifying which profile file belongs to an app
when multiple binaries are instrumented and dumping profiles into the
same directory. The filename includes the path.
Reviewers: davidxl
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D49529
llvm-svn: 337482
Fix bot failure from r37465. Move the new lto_flags append under the
check for whether lto_supported. Otherwise TestingConfig may not have
that member.
llvm-svn: 337467
Summary:
Executes both LTO and ThinLTO CFI tests an additional time using the new
pass manager. I only bothered to add with gold and not lld as testing
with one linker should be sufficient. I didn't add for APPLE or WIN32
since I don't have a way to test those.
Depends on D49429.
Reviewers: pcc
Subscribers: dberris, mgorny, mehdi_amini, delcypher, dexonsmith, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D49432
llvm-svn: 337465
This change makes it so that the profiling mode implementation will only
write files when there are buffers to write. Before this change, we'd
always open a file even if there were no profiles collected when
flushing.
llvm-svn: 337443
When providing raw access to the FDR mode buffers, we used to not
include the extents metadata record. This oversight means that
processing the buffers in-memory will lose important information that
would have been written in files.
This change exposes the metadata record by serializing the data
similarly to how we would do it when flushing to files.
llvm-svn: 337441
MAP_NORESERVE is not supported or a no-op on BSD.
Reviewers: dberris
Reviewed By: dberris
Differential Revision: https://reviews.llvm.org/D49494
llvm-svn: 337440
Summary:
We've been seeing intermittent failures on our internal bots and we suspect
this may be due to the OS scheduling the child process to run before the parent
process.
This version ensures that the parent and child can be run in either order.
Reviewers: Maknee, dberris
Reviewed By: dberris
Subscribers: delcypher, #sanitizers, Maknee, llvm-commits
Differential Revision: https://reviews.llvm.org/D49501
llvm-svn: 337432
This prevents gold from printing a warning when trying to export
these symbols via the asan dynamic list after ThinLTO promotes them
from private symbols to external symbols with hidden visibility.
Differential Revision: https://reviews.llvm.org/D49498
llvm-svn: 337428
Fuchsia doesn't have signals; instead it expects processes to have a
dedicated exception thread that binds to the process' exception port and
waits for exception packets to be delivered. On the other hand,
libFuzzer and sanitizer_common use expect to collect crash information
via libunwind from the same thread that caused the exception.
The long term fix is to improve support for remote unwinding in
libunbwind, plumb this through sanitizer_common and libFuzzer, and
handle the exception exclusively on the exception thread. In the
meantime, this revision has the exception thread "resurrect" the
crashing thread by:
* saving its general purpose register state onto the crashing thread's
stack,
* setting the crashing thread's program counter to an assembly trampoline
with the CFI information needed by libunwind, and
* resuming the crashed thread.
Patch By: aarongreen
Differential Revision: https://reviews.llvm.org/D48509
llvm-svn: 337418
Summary:
Created IterateInline8bitCounters, a single template for visiting Inline8bitCounters (nested for loop)
Made InitializeUnstableCounters and UpdateUnstableCounters both send a lambda to IterateInline8bitCounters.
Patch by Kyungtak Woo (@kevinwkt).
Reviewers: Dor1s, metzman, kcc, morehouse
Reviewed By: metzman, morehouse
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49453
llvm-svn: 337403
Summary:
This is a follow-on to D49217 which simplifies and optimises the
implementation of the segmented array. In this patch we co-locate the
book-keeping for segments in the `__xray::Array<T>` with the data it's
managing. We take the chance in this patch to actually rename `Chunk` to
`Segment` to better align with the high-level description of the
segmented array.
With measurements using benchmarks landed in D48879, we've identified
that calls to `pthread_getspecific` started dominating the cycles, which
led us to revert the change made in D49217 to use C++ thread_local
initialisation instead (it reduces the cost by a huge margin, since we
save one PLT-based call to pthread functions in the hot path). In
particular, this is in `__xray::getThreadLocalData()`.
We also took the opportunity to remove the least-common-multiple based
calculation and instead pack as much data into segments of the array.
This greatly simplifies the API of the container which hides as much of
the implementation details as possible. For instance, we calculate the
number of elements we need for the each segment internally in the Array
instead of making it part of the type.
With the changes here, we're able to get a measurable improvement on the
performance of profiling mode on top of what D48879 already provides.
Depends on D48879.
Reviewers: kpw, eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49363
llvm-svn: 337343
Summary:
This change simplifies the XRay Allocator implementation to self-manage
an mmap'ed memory segment instead of using the internal allocator
implementation in sanitizer_common.
We've found through benchmarks and profiling these benchmarks in D48879
that using the internal allocator in sanitizer_common introduces a
bottleneck on allocating memory through a central spinlock. This change
allows thread-local allocators to eliminate contention on the
centralized allocator.
To get the most benefit from this approach, we also use a managed
allocator for the chunk elements used by the segmented array
implementation. This gives us the chance to amortize the cost of
allocating memory when creating these internal segmented array data
structures.
We also took the opportunity to remove the preallocation argument from
the allocator API, simplifying the usage of the allocator throughout the
profiling implementation.
In this change we also tweak some of the flag values to reduce the
amount of maximum memory we use/need for each thread, when requesting
memory through mmap.
Depends on D48956.
Reviewers: kpw, eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49217
llvm-svn: 337342
Summary:
Fix a bug in FDR mode which didn't allow for re-initialising the logging
in the same process. This change ensures that:
- When we flush the FDR mode logging, that the state of the logging
implementation is `XRAY_LOG_UNINITIALIZED`.
- Fix up the thread-local initialisation to use aligned storage and
`pthread_getspecific` as well as `pthread_setspecific` for the
thread-specific data.
- Actually use the pointer provided to the thread-exit cleanup handling,
instead of assuming that the thread has thread-local data associated
with it, and reaching at thread-exit time.
In this change we also have an explicit test for two consecutive
sessions for FDR mode tracing, and ensuring both sessions succeed.
Reviewers: kpw, eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49359
llvm-svn: 337341
Summary:
Code now exists to track number of mutations that are used in fuzzing in total
and ones that produce new coverage. The stats are currently being dumped to the
command line.
Patch by Kodé Williams (@kodewilliams).
Reviewers: metzman, Dor1s, morehouse, kcc
Reviewed By: Dor1s, morehouse, kcc
Subscribers: delcypher, kubamracek, kcc, morehouse, llvm-commits, #sanitizers, mgorny
Differential Revision: https://reviews.llvm.org/D48054
llvm-svn: 337324
This function is available for linking in from kernel32.dll, but
it's not allowed to link that function from there in Windows Store
apps.
Differential Revision: https://reviews.llvm.org/D49055
llvm-svn: 337313
This is a fix for bug 37047.
https://bugs.llvm.org/show_bug.cgi?id=37047
Implemented by basically reversing the logic. Previously all strings
were considered, with some operations excluded. Now strings are excluded
by default, and only strings during the CB considered.
Patch By: pdknsk
Differential Revision: https://reviews.llvm.org/D48800
llvm-svn: 337296
We no longer pass CLANG_DEFAULT_CXX_STDLIB to the runtimes build
as it was causing issues so we can no longer use this variable. We
instead use cxx-headers as a dependency whenever this is available
since both XRay and libFuzzer are built as static libraries so this
is sufficient.
Differential Revision: https://reviews.llvm.org/D49346
llvm-svn: 337199
Summary:
Code now exists to track number of mutations that are used in fuzzing in total
and ones that produce new coverage. The stats are currently being dumped to the
command line.
Patch by Kodé Williams (@kodewilliams).
Reviewers: metzman, Dor1s, morehouse, kcc
Reviewed By: Dor1s, morehouse, kcc
Subscribers: delcypher, kubamracek, kcc, morehouse, llvm-commits, #sanitizers, mgorny
Differential Revision: https://reviews.llvm.org/D48054
llvm-svn: 337194
Summary:
Created a -print_unstable_stats flag.
When -print_unstable_stats=1, we run it 2 more times on interesting inputs poisoning unstable edges in an array.
On program termination, we run PrintUnstableStats() which will print a line with a stability percentage like AFL does.
Patch by Kyungtak Woo (@kevinwkt).
Reviewers: metzman, Dor1s, kcc, morehouse
Reviewed By: metzman, Dor1s, morehouse
Subscribers: delcypher, llvm-commits, #sanitizers, kcc, morehouse, Dor1s
Differential Revision: https://reviews.llvm.org/D49212
llvm-svn: 337187
Summary:
Created a -print_unstable_stats flag.
When -print_unstable_stats=1, we run it 2 more times on interesting inputs poisoning unstable edges in an array.
On program termination, we run PrintUnstableStats() which will print a line with a stability percentage like AFL does.
Patch by Kyungtak Woo (@kevinwkt).
Reviewers: metzman, Dor1s, kcc, morehouse
Reviewed By: metzman, Dor1s, morehouse
Subscribers: delcypher, llvm-commits, #sanitizers, kcc, morehouse, Dor1s
Differential Revision: https://reviews.llvm.org/D49212
llvm-svn: 337175
Summary:
Fix a TODO in CMake config for XRay tests to use the detected C++ ABI
library in the tests.
Also make the tests depend on the llvm-xray target when built in-tree.
Reviewers: kpw, eizan
Reviewed By: eizan
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D49358
llvm-svn: 337142
This changes the name and the type to what it was prior to r333037
which matches the name of the flag used in other runtimes: libc++,
libc++abi and libunwind. We don't need the type to be a string since
there's only binary choice between libgcc and compiler-rt unlike in
the case of C++ library where there're multiple options.
Differential Revision: https://reviews.llvm.org/D49325
llvm-svn: 337116
Summary:
That flag has been introduced in https://reviews.llvm.org/D48660 for
suppressing UIO error messages in an efficient way. The main motivation is to
be able to use UIO checks in builds used for fuzzing as it might provide an
interesting signal to a fuzzing engine such as libFuzzer.
See https://github.com/google/oss-fuzz/issues/910 for more information.
Reviewers: morehouse, kcc
Reviewed By: morehouse
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D49324
llvm-svn: 337068
Summary:
Introduce built-ins to read the unsafe stack top and bottom. The unsafe
stack top is required to implement garbage collection scanning for
Oilpan. Currently there is already a built-in 'get_unsafe_stack_start'
to read the bottom of the unsafe stack, but I chose to duplicate this
API because 'start' is ambiguous (e.g. Oilpan uses WTF::GetStackStart to
read the safe stack top.)
Reviewers: pcc
Reviewed By: pcc
Subscribers: llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D49152
llvm-svn: 337037
These are not necessarily correct, just because Clang is configured
to use libc++ or compiler-rt as defaults doesn't mean that the host
compiler uses these as defaults as well. A more correct solution
would be to test the host compiler to check what the default actually
is as attempted in D46857.
Part of PR-38025.
Differential Revision: https://reviews.llvm.org/D49272
llvm-svn: 337033
Summary:
Use `-Wl,-z,global` for all Sanitizer shared libraries on
Android. We want them to be in the global group
(https://android.googlesource.com/platform/bionic/+/master/android-changes-for-ndk-developers.md#changes-to-library-search-order)
to avoid any alloc/dealloc mismatch between the libc allocator & said library.
`audioserver` was one of the binary that exhibited the problem with Scudo,
this seems to fix it.
[edited for accuracy]
Reviewers: eugenis, alekseyshl
Reviewed By: eugenis
Subscribers: kubamracek, srhines, mgorny, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D49198
llvm-svn: 337010
Summary:
This test invokes undocumented behaviour that could change in
the future. Given this, it's probably best to just remove the
test.
rdar://problem/42022283
Reviewers: kubamracek
Subscribers: llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49269
llvm-svn: 336977
Summary:
llvm-xray changes:
- account-mode - process-id {...} shows after thread-id
- convert-mode - process {...} shows after thread
- parses FDR and basic mode pid entries
- Checks version number for FDR log parsing.
Basic logging changes:
- Update header version from 2 -> 3
FDR logging changes:
- Update header version from 2 -> 3
- in writeBufferPreamble, there is an additional PID Metadata record (after thread id record and tsc record)
Test cases changes:
- fdr-mode.cc, fdr-single-thread.cc, fdr-thread-order.cc modified to catch process id output in the log.
Reviewers: dberris
Reviewed By: dberris
Subscribers: hiraditya, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49153
llvm-svn: 336974
Summary:
This change adds support for writing out profiles at program exit.
Depends on D48653.
Reviewers: kpw, eizan
Reviewed By: kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48956
llvm-svn: 336969
Summary:
This allows counters associated with unused functions to be
dead-stripped along with their functions. This approach is the same one
we used for PC tables.
Fixes an issue where LLD removes an unused PC table but leaves the 8-bit
counter.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: llvm-commits, hiraditya, kcc
Differential Revision: https://reviews.llvm.org/D49264
llvm-svn: 336941
The list duplicates information already available in the parent
directory so use that instead. It is unclear to me why we need
to spell out the dependencies explicitly but fixing that should
be done in a separate patch.
Differential Revision: https://reviews.llvm.org/D49177
llvm-svn: 336905
The variable name `SANITIZER_HEADERS` is already used for the list of
public headers in `include/CMakeLists.txt`. Although the previous
implementation worked it's probably best to avoid shadowing global
variables to avoid confusion.
Differential Revision: https://reviews.llvm.org/D49176
llvm-svn: 336904
This constrains the build environments we are testing/supporting for the runtime
tests until we can be sure xray works in more platforms.
llvm-svn: 336878
Summary:
The write buffer contains signed chars, which means the shift operations caused values such as the arc tag value (0x01a10000) to be read incorrectly (0xffa10000).
This fixes a regression from https://reviews.llvm.org/D49132.
Reviewers: uweigand, davidxl
Reviewed By: uweigand
Subscribers: llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49161
llvm-svn: 336775
Summary: XRayRecords now includes a PID field. Basic handlers fetch pid and tid each time they are called instead of caching the value. Added a testcase that calls fork and checks if the child TID is different from the parent TID to verify that the processes' TID are different in the trace.
Reviewers: dberris, Maknee
Reviewed By: dberris, Maknee
Subscribers: kpw, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49025
llvm-svn: 336769
Summary:
A prior refactoring accidentally dropped the case for using libc++abi as
the out-of-tree C++ runtime library for sanitizers. This patch restores
that functionality, which is used by Android, which can't depend on the
full libc++ for these libraries.
Reviewers: phosek, EricWF
Reviewed By: phosek
Subscribers: meikeb, kongyi, chh, mgorny, delcypher, llvm-commits, #sanitizers, pirama
Differential Revision: https://reviews.llvm.org/D49157
llvm-svn: 336749
Summary:
After my recent change to allow MSan + libFuzzer, the
ExplodeDFSanLabelsTest.cpp test started to overflow the stack with
recursive function SetBytesForLabel() on an AArch64 bot. Perhaps that
bot has a smaller stack size, or maybe AArch64 has larger stack frames
for this particular function.
Reviewers: kcc, javed.absar
Reviewed By: kcc
Subscribers: kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D49150
llvm-svn: 336725
This reverts rL334510 due to breakage of afl_driver's command line
interface.
Patch By: Jonathan Metzman
Differential Revision: https://reviews.llvm.org/D49141
llvm-svn: 336719
The test case fails on the big-endian PPC bot, probably because PowerPC
uses function descriptors. More over other architectures don't support
NX mappings. (This test case was not being exercised prior to r336633.)
llvm-svn: 336714
Processors before z14 don't support non-execute protection,
so they will start execution random memory contents, causing
the test to randomly fail or succeed.
llvm-svn: 336705
It turns out that the `${XRAY_HEADERS}` CMake variable was already
in use and was used for public headers. It seems that
`lib/xray/tests/CMakeLists.txt` was depending on this.
To fix rename the new `${XRAY_HEADERS}` to `${XRAY_IMPL_HEADERS}`.
llvm-svn: 336699
Two fixes required to handle big-endian systems:
- 64-bit counter values are stored in a mixed-endian format in the
gcov files: a 32-bit low-part followed by a 32-bit high part. Note that
this is already implemented correctly on the LLVM side, see
GCOVBuffer::readInt64.
- The tag values (e.g. arcs tag, object summary tag, ...) are aways
written as the same sequence of bytes independent of byte order. But
when *reading* them back in, the code reads them as 32-bit values in
host byte order. For the comparisons to work correctly, this should
instead always read them as little-endian values.
Fixes PR 38121.
Reviewed By: marco-c
Differential Revision: https://reviews.llvm.org/D49132
llvm-svn: 336693
when building with an IDE so that header files show up in the UI.
This massively improves the development workflow in IDEs.
To implement this a new function `compiler_rt_process_sources(...)` has
been added that adds header files to the list of sources when the
generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no
changes are made to the list of source files.
The function can be passed a list of headers via the
`ADDITIONAL_HEADERS` argument. For each runtime library a list of
explicit header files has been added and passed via
`ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of
headers was already present but it was stale and has been updated
to reflect the current state of the source tree.
The original version of this patch used file globbing (`*.{h,inc,def}`)
to find the headers but the approach was changed due to this being a
CMake anti-pattern (if the list of headers changes CMake won't
automatically re-generate if globbing is used).
The LLVM repo contains a similar function named `llvm_process_sources()`
but we don't use it here for several reasons:
* It depends on the `LLVM_ENABLE_OPTION` cache variable which is
not set in standalone compiler-rt builds.
* We would have to `include(LLVMProcessSources)` which I'd like to
avoid because it would include a bunch of stuff we don't need.
Differential Revision: https://reviews.llvm.org/D48422
llvm-svn: 336663
Summary:
Original patch by Kuba Mracek
The %T lit expansion expands to a common directory shared between all
the tests in the same directory, which is unexpected and unintuitive,
and more importantly, it's been a source of subtle race conditions and
flaky tests. In https://reviews.llvm.org/D35396, it was agreed that it
would be best to simply ban %T and only keep %t, which is unique to each
test. When a test needs a temporary directory, it can just create one
using mkdir %t.
This patch removes %T in compiler-rt.
Differential Revision: https://reviews.llvm.org/D48618
llvm-svn: 336661
Changes:
- Remove static assertion on size of a structure, fails on systems where
pointers aren't 8 bytes.
- Use size_t instead of deducing type of arguments to
`nearest_boundary`.
Follow-up to D48653.
llvm-svn: 336648
Summary:
We found a bug while working on a benchmark for the profiling mode which
manifests as a segmentation fault in the profiling handler's
implementation. This change adds unit tests which replicate the
issues in isolation.
We've tracked this down as a bug in the implementation of the Freelist
in the `xray::Array` type. This happens when we trim the array by a
number of elements, where we've been incorrectly assigning pointers for
the links in the freelist of chunk nodes. We've taken the chance to add
more debug-only assertions to the code path and allow us to verify these
assumptions in debug builds.
In the process, we also took the opportunity to use iterators to
implement both `front()` and `back()` which exposes a bug in the
iterator decrement operation. In particular, when we decrement past a
chunk size boundary, we end up moving too far back and reaching the
`SentinelChunk` prematurely.
This change unblocks us to allow for contributing the non-crashing
version of the benchmarks in the test-suite as well.
Reviewers: kpw
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D48653
llvm-svn: 336644
Summary:
Some tests already make use of OS feature names, e.g. 'linux' and 'freebsd',
but they are not actually currently set by lit.
Reviewers: pcc, eugenis
Reviewed By: eugenis
Subscribers: emaste, krytarowski, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49115
llvm-svn: 336633
Code now exists to track number of mutations that are used in fuzzing in
total and ones that produce new coverage. The stats are currently being
dumped to the command line.
Patch By: Kode Williams
Differntial Revision: https://reviews.llvm.org/D48054
llvm-svn: 336597
Summary:
- use proper Error() decorator for error messages
- refactor ASan thread id and name reporting
Reviewers: eugenis
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D49044
llvm-svn: 336573
Summary: This is a minor cosmetic change. When function/path exceed ~1000 characters, the output is truncated before the line-break. I noticed this for NEW_FUNC.
Reviewers: kcc
Reviewed By: kcc
Subscribers: llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D48799
llvm-svn: 336461
Summary:
Namely, set the abort message, and allow to write the message to syslog if the
option is enabled.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48902
llvm-svn: 336445
Summary:
This will make the behavior of __gcov_flush match the GCC behavior.
I would like to rename __gcov_flush to __llvm_gcov_flush (in case of programs linking to libraries built with different compilers), but I guess we can't for compatibility reasons.
Reviewers: davidxl
Reviewed By: davidxl
Subscribers: samsonov, vitalybuka, pcc, kcc, junbuml, glider, fhahn, eugenis, dvyukov, davidxl, srhines, chh, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D48538
llvm-svn: 336365
Summary:
The C interceptors were using `SIZE_T` defined in the interception library as
a `__sanitizer::uptr`. On some 32-bit platforms, this lead to the following
warning:
```
warning: declaration of ‘void* malloc(SIZE_T)’ conflicts with built-in declaration ‘void* malloc(unsigned int)’ [-Wbuiltin-declaration-mismatch]
INTERCEPTOR_ATTRIBUTE void *malloc(SIZE_T size) {
```
`__sanitizer::uptr` is indeed defined as an `unsigned long` on those.
So just include `stddef.h` and use `size_t` instead.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D48885
llvm-svn: 336221
Summary:
In conjunction with the clang side change D48833, this will enable Scudo on
PPC64. I tested `check-scudo` on a powerpc64le box and everything passes.
Reviewers: eugenis, alekseyshl
Reviewed By: alekseyshl
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48834
llvm-svn: 336213
Summary:
It would be useful for Flutter apps, especially, to be able to use
malloc hooks to debug memory leaks on Fuchsia. They're not able to do
this right now, so it'd be a nice bonus to throw in with the Scudo
switchover.
Reviewers: cryptoad, alekseyshl
Reviewed By: cryptoad
Differential Revision: https://reviews.llvm.org/D48618
llvm-svn: 336139
Summary:
Without this patch,
clang -fsanitize=address -xc =(printf 'int main(){}') -o a; ./a => deadlock in __asan_init>AsanInitInternal>AsanTSDInit>...>__getcontextx_size>_rtld_bind>rlock_acquire(rtld_bind_lock, &lockstate)
libexec/rtld-elf/rtld.c
wlock_acquire(rtld_bind_lock, &lockstate);
if (obj_main->crt_no_init)
preinit_main(); // unresolved PLT functions cannot be called here
lib/libthr/thread/thr_rtld.c
uc_len = __getcontextx_size(); // unresolved PLT function in libthr.so.3
check-xray tests currently rely on .preinit_array so we special case in
xray_init.cc
Subscribers: srhines, kubamracek, krytarowski, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D48806
llvm-svn: 336067
Currently in FreeBSD 12.0-CURRENT with trunk clang+compiler-rt, faulty -fsanitize=address executable hangs at 'urdlck' state.
Ka Ho Ng has verified that by backporting this to llvm 6.0.1, with use_madv_dontdump=1, shadow memory is not dumped.
ASAN_OPTIONS=abort_on_error=1:disable_coredump=0:use_madv_dontdump=1 ./a
Reviewers: dimitry, kcc, dvyukov, emaste, khng300
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D48257
llvm-svn: 336046
__gcov_flush is hidden.
For applications to dump profiling data of selected .so files,
they can use dlsym to find and call llvm_gcov_flush in each .so file.
Differential Revision: https://reviews.llvm.org/D45454
llvm-svn: 336019
The test checks that scs does NOT work correctly w/o runtime support.
That's a strange thing to test, and it is also flaky, because things
may just work if x18 happens to point to a writable page.
llvm-svn: 335982
Summary:
As well as some tests to ensure that various combinations of the clang command
line flags work (shared/static/minimal).
Reviewers: eugenis, alekseyshl, vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48553
llvm-svn: 335981
This change makes it pass both on libstdc++ and libc++-based toolchains.
The error was:
error: function-like macro '__GLIBC_PREREQ' is not defined
^
llvm-svn: 335936
NDK r16 provides glob.h, which makes this test pass.
Supporting different test outcomes depending on the version of NDK
add unnecessary complexity to the test harness. IMHO, it's OK to require
the latest stable release.
llvm-svn: 335935
Summary:
Report errno value on failed shadow memory madvise attempt and add a
hint message with the possible workaround.
Reviewers: eugenis
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48668
llvm-svn: 335928
This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:
lib/clang/$version/lib/$os
Clang now allows runtimes to be installed to:
lib/clang/$version/$target/lib
This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.
The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.
Differential Revision: https://reviews.llvm.org/D45604
llvm-svn: 335809
Under load, these tests tend to fail sporadically on our bots.
In my understanding, the signal handling is not guaranteed to happen
within 2 seconds, and the test is inherently flaky.
llvm-svn: 335792
The android buildbot moves the build outputs to a different directory
and rewrites the executable path, the DSO passed as an argument does not
get re-written. Use rpaths to load the DSO the same way the
test/cfi/cross-dso/ tests do and test the DSO name differently.
llvm-svn: 335777
Summary:
Setting UBSAN_OPTIONS=silence_unsigned_overflow=1 will silence all UIO
reports. This feature, combined with
-fsanitize-recover=unsigned-integer-overflow, is useful for providing
fuzzing signal without the excessive log output.
Helps with https://github.com/google/oss-fuzz/issues/910.
Reviewers: kcc, vsk
Reviewed By: vsk
Subscribers: vsk, kubamracek, Dor1s, llvm-commits
Differential Revision: https://reviews.llvm.org/D48660
llvm-svn: 335762
On Darwin/x86_64, asan may report the crashing line of NullDeref as line
19 (i.e the closing brace of the function), whereas on other targets we
see line 15 ("ptr[10]++").
The optimized debug info here isn't reliable enough to check.
rdar://problem/41526369
llvm-svn: 335747
On some ARM platforms this test depends on debug locations being
present on constant materialization code, which was eliminated in
r335497.
Relax the test to allow two outcomes: the backtrace either contains the
right line numbers, or no line numbers.
llvm-svn: 335741
build with an IDE (e.g. Xcode) as the generator.
Previously the global `USE_FOLDERS` property wasn't set in standalone
builds leading to existing settings of FOLDER not being respected.
In addition to this there were several targets that appeared at the top
level that were not interesting and clustered up the view. These have
been changed to be displayed in "Compiler-RT Misc".
Now when an Xcode project is generated from a standalone compiler-rt
build the project navigator is much less cluttered. The interesting
libraries should appear in "Compiler-RT Libraries" in the IDE.
Differential Revision: https://reviews.llvm.org/D48378
llvm-svn: 335728
Some warnings originating from googletest were causing bots to fail
while bulding unit tests. The sanitizers address this issue by not
using -Werror. We adopt this approach for libFuzzer.
llvm-svn: 335640
Similarly to CFI on virtual and indirect calls, this implementation
tries to use program type information to make the checks as precise
as possible. The basic way that it works is as follows, where `C`
is the name of the class being defined or the target of a call and
the function type is assumed to be `void()`.
For virtual calls:
- Attach type metadata to the addresses of function pointers in vtables
(not the functions themselves) of type `void (B::*)()` for each `B`
that is a recursive dynamic base class of `C`, including `C` itself.
This type metadata has an annotation that the type is for virtual
calls (to distinguish it from the non-virtual case).
- At the call site, check that the computed address of the function
pointer in the vtable has type `void (C::*)()`.
For non-virtual calls:
- Attach type metadata to each non-virtual member function whose address
can be taken with a member function pointer. The type of a function
in class `C` of type `void()` is each of the types `void (B::*)()`
where `B` is a most-base class of `C`. A most-base class of `C`
is defined as a recursive base class of `C`, including `C` itself,
that does not have any bases.
- At the call site, check that the function pointer has one of the types
`void (B::*)()` where `B` is a most-base class of `C`.
Differential Revision: https://reviews.llvm.org/D47567
llvm-svn: 335569
OpenBSD needs lld linker for sanitisers.
Disabling lint checking as some symbols cannot be defined and block the proper unit tests launch.
Reviewers: lebedev.ri, vitalybuka
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D48528
llvm-svn: 335524
__ubsan_on_report isn't defined as weak, and redefining it in a test is
not supported on Windows.
See the error message here: https://reviews.llvm.org/D48446
llvm-svn: 335523
Speculative fix for the interface definition of __ubsan_on_report for
the Windows bots:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/30528
lib\ubsan\ubsan_interface.inc(55): error C2065: '__ubsan_on_report':
undeclared identifier
INTERCEPT_SANITIZER_WEAK_FUNCTION was the wrong macro to use to begin
with because __ubsan_on_report isn't weak. Reading through that macro,
it's still not clear to me why there is an undefined reference, though,
because it appears to define a dummy __ubsan_on_report shim.
llvm-svn: 335383
Add support to the ubsan runtime for reporting diagnostics to a monitor
process (e.g a debugger).
The Xcode IDE uses this by setting a breakpoint on __ubsan_on_report and
collecting diagnostic information via __ubsan_get_current_report_data,
which it then surfaces to users in the editor UI.
Testing for this functionality already exists in upstream lldb, here:
lldb/packages/Python/lldbsuite/test/functionalities/ubsan
Apart from that, this is `ninja check-{a,ub}san` clean.
Differential Revision: https://reviews.llvm.org/D48446
llvm-svn: 335371
MutexUnlock uses ReleaseStore on s->clock, which is the right thing to do.
However MutexReadOrWriteUnlock for writers uses Release on s->clock.
Make MutexReadOrWriteUnlock also use ReleaseStore for consistency and performance.
Unfortunately, I don't think any test can detect this as this only potentially
affects performance.
llvm-svn: 335322
Summary:
This patch follows D48373.
The point is to be able to use Scudo with `-fsanitize-minimal-runtime`. For that
we need a runtime that doesn't embed the UBSan one. This results in binaries
that can be compiled with `-fsanitize=scudo,integer -fsanitize-minimal-runtime`.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: mgorny, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D48377
llvm-svn: 335296
Similarly to Msan adding -pie provokes linkage issue, was spotted with pie_test.cc
Set to XFAIL for couple of unit tests.
Reviewers: vitalybuka, krytarowski, dim
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D48317
llvm-svn: 335166
Intercepts thr_exit call on FreeBSD.
Disable pthread key workflow.
The pthread key create approach does not function under FreeBSD as the libpthread is not initialised enough at this stage.
Reviewers: vitalybuka, krytarowski, dim
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D48268
llvm-svn: 335164
Summary:
Remove the generic error nadling policies and handle each allocator error
explicitly. Although more verbose, it allows for more comprehensive, precise
and actionable allocator related failure reports.
This finishes up the series of changes of the particular sanitizer
allocators, improves the internal allocator error reporting and removes
now unused policies.
Reviewers: vitalybuka, cryptoad
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48328
llvm-svn: 335147
There's more platforms than just "ios" and "iossim" that we should support, and adding more lit config variables for each platform isn't great. Let's generalize and have a single value that determines what the platform under test is.
Differential Revision: https://reviews.llvm.org/D48309
llvm-svn: 335123
Summary:
Mark `isRssLimitExceeded` as `NOINLINE`, and move it's definition as well as
the one of `performSanityChecks` out of the class definition, as requested.
Reviewers: filcab, alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48228
llvm-svn: 335054
Summary: `rm -f` does not write diagnostic message when there is no file argument.
Reviewers: dberris
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D48311
llvm-svn: 335025
The initial implementaiton was using the C++ typeof keyword. This
causes the compiler to spew warnings unnecissarilly. This patch removes
the uses of typeof and replaces them with explicit typedefs of the
function types.
llvm-svn: 334981
Summary:
Following up on and complementing D44404 and other sanitizer allocators.
Currently many allocator specific errors (OOM, for example) are reported as
a text message and CHECK(0) termination, no stack, no details, not too
helpful nor informative. To improve the situation, detailed and structured
common errors were defined and reported under the appropriate conditions.
Common tests were generalized a bit to cover a slightly different TSan
stack reporting format, extended to verify errno value and returned
pointer value check is now explicit to facilitate debugging.
Reviewers: dvyukov
Subscribers: srhines, kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48087
llvm-svn: 334975
Marco Castelluccio