| Age | Commit message (Collapse) | Author |
|---|
|
Add a ANDROID_SERIAL_FOR_TESTING CMake variable. This lets you
run the tests with multiple devices attached without having to set
ANDROID_SERIAL.
Add a mechanism for pushing files to the device. Currently most
sanitizers require llvm-symbolizer and the sanitizer runtime to
be pushed to the device. This lets the sanitizer make this happen
automatically before running the tests by specifying the paths in
the lit.site.cfg file.
Differential Revision: https://reviews.llvm.org/D56712
|
|
|
|
-pie -Wl,--enable-new-dtags are no longer needed because
the driver passes them by default as of r316606.
Prepend -fuse-ld=gold instead of appending it so that the linker can
be overridden using COMPILER_RT_TEST_COMPILER_CFLAGS.
Differential Revision: https://reviews.llvm.org/D56697
|
|
In last year's update (D48219) it was suggested that the release manager
might want to do this, so here we go.
|
|
|
|
Reviewers: krytarowski, vitalybuka
Reviewed By: krytarowski
Differential Revision: https://reviews.llvm.org/D56670
|
|
android, un-XFAIL it.
|
|
|
|
Summary:
This is the compiler-rt part.
The clang part is D54589.
This is a second commit, the original one was r351106,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.
Now, i have fundamentally changed the testing approach:
i malloc a few bytes, intentionally mis-align the pointer
(increment it by one), and check that. Also, i have decreased
the expected alignment. This hopefully should be enough to pacify
all the bots. If not, i guess i might just drop the two 'bad' tests.
Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse
Reviewed By: morehouse
Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D54590
|
|
Summary:
The test uses `nullptr` which can break running the test if the
compiler happens to be using something older than C++11 as the default
language standard. Avoid this by explicitly setting the standard.
rdar://problem/47253542
Reviewers: eugenis, yln, vitalybuka
Subscribers: kubamracek, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D56667
|
|
Revert r351104-6, r351109, r351110, r351119, r351134, and r351153. These
changes fail on the sanitizer bots.
|
|
r351134 tried to disable these tests by using 'UNSUPPORTED: *' but '*'
is not supported for UNSUPPORTED like it is for XFAIL. Update these
tests to use XFAIL for now in order to silence x86_64-linux and
x86_64-linux-android.
|
|
Summary:
Use alternatename for external functions only when using
MSVC since Clang doesn't support it and MSVC doesn't support
Clang's method (weak aliases).
Reviewers: morehouse
Reviewed By: morehouse
Subscribers: rnk, thakis, mgorny
Differential Revision: https://reviews.llvm.org/D56514
|
|
for now.
And they are faling on clang-cmake-armv7-full too.
*ONLY* these two.
I'm not sure what to make of it.
Perhaps doing a malloc and checking that pointer will
make them fail as expected?
|
|
Once again, just like with r338296, these tests seem to only have
failed sanitizer-x86_64-linux-android, so let's just disable them,
since that seems like the pre-established practice here..
To be noted, they failed on some configs there, but not all,
so it is not XFAIL.
|
|
Having libc++ checked out doesn't necessarily mean it should be built;
for example, the same source tree might be used for multiple build
configurations, and libc++ might not build in some of those
configurations. Add an option to compiler-rt's build to disable building
libc++. This defaults to ON, so it shouldn't change any existing build
configurations.
Differential Revision: https://reviews.llvm.org/D56479
|
|
Somehow this escaped my local testing.
A follow-up for r351106.
|
|
Disable tests requiring sunrpc when the relevant headers are missing.
In order to accommodate that, move the header check
from sanitizer_common to base-config-ix, and define the check result
as a global variable there. Use it afterwards both for definition
needed by sanitizer_common, and to control 'sunrpc' test feature.
While at it, remove the append_have_file_definition macro that was used
only once, and no longer fits the split check-definition.
Bug report: https://github.com/google/sanitizers/issues/974
Differential Revision: https://reviews.llvm.org/D47819
|
|
Summary:
This is the compiler-rt part.
The clang part is D54589.
Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse
Reviewed By: morehouse
Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D54590
|
|
This reverts r350806 which marked some tests as UNSUPPORTED on ARM and
instead reintroduces the old code path only for Thumb, since that seems
to be the only target that broke.
It would still be nice to find the root cause of the breakage, but with
the branch point for LLVM 8.0 scheduled for next week it's better to put
things in a stable state while we investigate.
Differential Revision: https://reviews.llvm.org/D56594
|
|
No need to pay function call overhead for a function that returns a
constant.
|
|
of writing to stdout.
This makes the script a little more gn friendly; gn does not support
redirecting the output of a script.
Differential Revision: https://reviews.llvm.org/D56579
|
|
LLVM started exporting targets for utilites with https://reviews.llvm.org/rL350959, which broke compiler-rt standalone builds because it was used to define FileCheck manually.
Changed this, so FileCheck gets imported now.
|
|
Reviewers: vitalybuka, pcc, eugenis
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D56583
|
|
Summary:
This fixes linker errors that occurs when the
`sanitizer_type_traits_test.cc` is built without optimizations.
The error occurs because the test tries to take a reference.
A possible workaround is to give the GTest macros take boolean rvalues
by doing something like:
```
ASSERT_TRUE(bool(is_same<uptr, uptr>::value));
```
However this only hides the problem. Unfortunately Using `constexpr`
won't fix the problem unless we are using C++17.
Reviewers: vitalybuka, kubamracek, george.karpenkov, yln
Subscribers: mgorny, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D56035
|
|
Android does not implement [set|get|end]usershell().
|
|
- If entries are properly copied (there were a bug in FreeBSD implementation in earlier version), or list properly reset.
Reviewers: vitalybuka, krytarowski
Reviewed By: krytarowski
Differential Revision: https://reviews.llvm.org/D56562
|
|
Summary:
It has been superseded by the `ignore_noninstrumented_modules` flag and is no longer needed.
Also simplify a test that checks that `mmap_interceptor` respects ignore annotations (`thr->ignore_reads_and_writes `).
Relevant: https://reviews.llvm.org/rL269855
<rdar://problem/46263073> Remove obsolete Apple-specific suppression option
Reviewers: dcoughlin, kubamracek, dvyukov, delcypher
Reviewed By: dvyukov
Subscribers: jfb, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D55075
|
|
Differential Revision: https://reviews.llvm.org/D56109
|
|
Remove the partial support for rpc/xdr.h from libtirpc. Since it is
an entirely external library, we ought to build it sanitized separately
and not attempt to intercept like the libc implementation. Besides,
the existing code for tirpc support was neither complete nor working.
Noted by @krytarowski.
Differential Revision: https://reviews.llvm.org/D47817
|
|
This patch implements the long double __floattitf (int128_t) method for
PowerPC -- specifically to convert a 128 bit integer into a long double
(IBM double-double).
To invoke this method, one can do so by linking against compiler-rt, via the
--rtlib=compiler-rt command line option supplied to clang.
Differential Revision: https://reviews.llvm.org/D54313/
|
|
This patch implements the __uint128_t __fixunstfti (long double) method for
PowerPC -- specifically to convert a long double (IBM double-double) to an
unsigned 128 bit integer.
The general approach of this algorithm is to convert the high and low doubles
of the long double and add them together if the doubles fit within 64 bits.
However, additional adjustments and scaling is performed when the high or low
double does not fit within a 64 bit integer.
To invoke this method, one can do so by linking against compiler-rt, via the
--rtlib=compiler-rt command line option supplied to clang.
Differential Revision: https://reviews.llvm.org/D54911
|
|
Temporarily mark a couple of tests as UNSUPPORTED until we figure out
why they fail on the thumb bots.
The failure was introduced in
r350139 - Add support for background thread on NetBSD in ASan.
|
|
Reviewers: krytarowski
Reviewed By: krytarowski
Differential Revision: https://reviews.llvm.org/D56495
|
|
Summary:
Replace calls to builtin functions with macros or functions that call the
Windows-equivalents when targeting windows and call the original
builtin functions everywhere else.
This change makes more parts of libFuzzer buildable with MSVC.
Reviewers: vitalybuka
Reviewed By: vitalybuka
Subscribers: mgorny, rnk, thakis
Differential Revision: https://reviews.llvm.org/D56439
|
|
- Assertion fails in the third iteration.
Reviewers: krytarowski
Reviewed By: krytarowski
Differential Revision: https://reviews.llvm.org/D56497
|
|
XFAIL the tests known to fail with glibc-2.27+. This takes away
the burden of handling known failures from users, and ensures that
we will be verbosely informed when they actually start working again.
Bug report: https://bugs.llvm.org/show_bug.cgi?id=37804
Differential Revision: https://reviews.llvm.org/D56062
|
|
Now that memory intrinsics are instrumented, it's more likely that
CheckAddressSized will be called with size 0. (It was possible before
with IR like:
%val = load [0 x i8], [0 x i8]* %ptr
but I don't think clang will generate IR like that and the optimizer
would normally remove it by the time it got anywhere near our pass
anyway). The right thing to do in both cases is to disable the
addressing checks (since the underlying memory intrinsic is a no-op),
so that's what we do.
Differential Revision: https://reviews.llvm.org/D56465
|
|
- Is a file descriptor flavor FreeBSD's specific.
- reentrant version included.
Reviewers: vitalybuka, krytarowski, emaste
Reviewed By: emaste
Differential Revision: https://reviews.llvm.org/D56268
|
|
Provide an implementation of MemoryMappingLayout::Error() for Mac.
|
|
Summary:
This patch lets ASan run when /proc is not accessible (ex. not mounted
yet). It includes a special test-only flag that emulates this condition
in an unpriviledged process.
This only matters on Linux, where /proc is necessary to enumerate
virtual memory mappings.
Reviewers: vitalybuka, pcc, krytarowski
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D56141
|
|
Summary:
Objective-C employs tagged pointers, that is, small objects/values may be encoded directly in the pointer bits. The resulting pointer is not backed by an allocation/does not point to a valid memory. TSan infrastructure requires a valid address for `Acquire/Release` and `Mutex{Lock/Unlock}`.
This patch establishes such a mapping via a "dummy allocation" for each encountered tagged pointer value.
Reviewers: dcoughlin, kubamracek, dvyukov, delcypher
Reviewed By: dvyukov
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D56238
|
|
This is the deprecated legacy interface, replace it with the current
_zx_vmar_allocate one.
Differential Revision: https://reviews.llvm.org/D56360
|
|
This reapplies commit r348984.
|
|
We still need the interceptor on non-aarch64 to untag the pthread_t
and pthread_attr_t pointers and disable tagging on allocations done
internally by glibc.
|
|
The dynamic loader on Android O appears to have a bug where it crashes
when dlopening DF_1_GLOBAL libraries.
|
|
Summary:
The default setting kTabSizeLog=20 results in an 8Mb global hash table,
almost all of it in private pages. That is not a sane setting in a
mobile, system-wide use case: with ~150 concurrent processes stack
depot will account for more than 1Gb of RAM.
Reviewers: kcc, pcc
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D56333
|
|
The problem is similar to D55986 but for threads: a process with the
interceptor hwasan library loaded might have some threads started by
instrumented libraries and some by uninstrumented libraries, and we
need to be able to run instrumented code on the latter.
The solution is to perform per-thread initialization lazily. If a
function needs to access shadow memory or add itself to the per-thread
ring buffer its prologue checks to see whether the value in the
sanitizer TLS slot is null, and if so it calls __hwasan_thread_enter
and reloads from the TLS slot. The runtime does the same thing if it
needs to access this data structure.
This change means that the code generator needs to know whether we
are targeting the interceptor runtime, since we don't want to pay
the cost of lazy initialization when targeting a platform with native
hwasan support. A flag -fsanitize-hwaddress-abi={interceptor,platform}
has been introduced for selecting the runtime ABI to target. The
default ABI is set to interceptor since it's assumed that it will
be more common that users will be compiling application code than
platform code.
Because we can no longer assume that the TLS slot is initialized,
the pthread_create interceptor is no longer necessary, so it has
been removed.
Ideally, lazy initialization should only cost one instruction in the
hot path, but at present the call may cause us to spill arguments
to the stack, which means more instructions in the hot path (or
theoretically in the cold path if the spills are moved with shrink
wrapping). With an appropriately chosen calling convention for
the per-thread initialization function (TODO) the hot path should
always need just one instruction and the cold path should need two
instructions with no spilling required.
Differential Revision: https://reviews.llvm.org/D56038
|
|
interceptor mode.
The Android dynamic loader has a non-standard feature that allows
libraries such as the hwasan runtime to interpose symbols even after
the symbol already has a value. The new value of the symbol is used to
relocate libraries loaded after the interposing library, but existing
libraries keep the old value. This behaviour is activated by the
DF_1_GLOBAL flag in DT_FLAGS_1, which is set by passing -z global to
the linker, which is what we already do to link the hwasan runtime.
What this means in practice is that if we have .so files that depend
on interceptor-mode hwasan without the main executable depending on
it, some of the libraries in the process will be using the hwasan
allocator and some will be using the system allocator, and these
allocators need to interact somehow. For example, if an instrumented
library calls a function such as strdup that allocates memory on
behalf of the caller, the instrumented library can reasonably expect
to be able to call free to deallocate the memory.
We can handle that relatively easily with hwasan by using tag 0 to
represent allocations from the system allocator. If hwasan's realloc
or free functions are passed a pointer with tag 0, the system allocator
is called.
One limitation is that this scheme doesn't work in reverse: if an
instrumented library allocates memory, it must free the memory itself
and cannot pass ownership to a system library. In a future change,
we may want to expose an API for calling the system allocator so
that instrumented libraries can safely transfer ownership of memory
to system libraries.
Differential Revision: https://reviews.llvm.org/D55986
|
|
Summary:
Replace the 32-bit allocator with a 64-bit one with a non-constant
base address, and reduce both the number of size classes and the maximum
size of per-thread caches.
As measured on [1], this reduces average weighted memory overhead
(MaxRSS) from 26% to 12% over stock android allocator. These numbers
include overhead from code instrumentation and hwasan shadow (i.e. not a
pure allocator benchmark).
This switch also enables release-to-OS functionality, which is not
implemented in the 32-bit allocator. I have not seen any effect from
that on the benchmark.
[1] https://android.googlesource.com/platform/system/extras/+/master/memory_replay/
Reviewers: vitalybuka, kcc
Subscribers: kubamracek, cryptoad, llvm-commits
Differential Revision: https://reviews.llvm.org/D56239
|
