__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
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
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
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
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
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: `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
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
Summary:
Using associated metadata rather than llvm.used allows linkers to
perform dead stripping with -fsanitize-coverage=pc-table. Unfortunately
in my local tests, LLD was the only linker that made use of this metadata.
Partially addresses https://bugs.llvm.org/show_bug.cgi?id=34636 and fixes
https://github.com/google/sanitizers/issues/971.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: Dor1s, hiraditya, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D48203
llvm-svn: 334858
Summary:
The current `FailureHandler` mechanism was fairly opaque with regard to the
failure reason due to using `CHECK(0)`. Scudo is a bit different from the other
Sanitizers as it prefers to avoid spurious processing in its failure path. So
we just `dieWithMessage` using a somewhat explicit string.
Adapted the tests for the new strings.
While this takes care of the `OnBadRequest` & `OnOOM` failures, the next step
is probably to migrate the other Scudo failures in the same failes (header
corruption, invalid state and so on).
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: filcab, mgorny, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48199
llvm-svn: 334843
David Carlier