Currently these files are being installed into a root installation
directory, but this triggers an error when the installation directory
is set to an empty string which is often the case when DESTDIR is
used to control the installation destination.
Differential Revision: https://reviews.llvm.org/D41673
llvm-svn: 322153
As discussed in the mail thread <https://groups.google.com/a/isocpp.org/forum/
#!topic/std-discussion/T64_dW3WKUk> "Calling noexcept function throug non-
noexcept pointer is undefined behavior?", such a call should not be UB.
However, Clang currently warns about it.
This change removes exception specifications from the function types recorded
for -fsanitize=function, both in the functions themselves and at the call sites.
That means that calling a non-noexcept function through a noexcept pointer will
also not be flagged as UB. In the review of this change, that was deemed
acceptable, at least for now. (See the "TODO" in compiler-rt
test/ubsan/TestCases/TypeCheck/Function/function.cpp.)
This is the compiler-rt part of a patch covering both cfe and compiler-rt.
Differential Revision: https://reviews.llvm.org/D40720
llvm-svn: 321860
NDK < 13 & API_LEVEL < 21 do not define struct mmsghdr.
Newer NDK use unified headers and provide this definition for all api
levels.
Since we can not check for the NDK version, check the api level. This
is more strict than absolutely necessary, but it does not really
matter: it is only a sanity check.
llvm-svn: 321817
Summary:
It used to fail on the bots, but I could not repro it locally. So turn it back
on to try and see if it still fails and maybe get to the heart of it.
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: aemerson, srhines, kristof.beyls, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D41707
llvm-svn: 321812
Summary:
`__scudo_set_rss_limit`'s `LimitMb` should really be a `size_t`. Update
accordingly the prototype. To avoid the `NOLINT` and conform with the other
Sanitizers, use the sanitizers types for the internal definition. This should
have no functional change.
Additionally, capitalize a variable name to follow the LLVM coding standards.
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41704
llvm-svn: 321803
We're having some use cases where we have more than 128 (the current maximum) instrumented dynamic libraries loaded into a single process. Let's bump the limit to 1024, and separate the constants.
Differential Revision: https://reviews.llvm.org/D41190
llvm-svn: 321782
Summary: Extend the sendmsg test to cover all recv*.
Reviewers: vitalybuka
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D41620
llvm-svn: 321774
Summary:
This way new asan_device_setup, which knows about the quirks of
recent releases of Android, can be used with older ASan runtime
library (say, from an NDK release). The library is version locked to
the compiler, and is often hard or impossible to update.
Reviewers: vitalybuka
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D41679
llvm-svn: 321677
This macro is only defined after XCode 8, causing build breakage for
build systems with prior versions. Ignore DISPATCH_NOESCAPE if not
defined.
Differential Revision: https://reviews.llvm.org/D41601
llvm-svn: 321543
...when such an operation is done on an object during con-/destruction.
(This adds a test case to compiler-rt/test/ubsan/TestCases/TypeCheck/vptr.cpp
that, unlike the existing test cases there, wants to detect multiple UBSan
warnings in one go. Therefore, that file had to be changed from globally using
-fno-sanitize-recover to individually using halt_on_error only where
appropriate.)
This is the compiler-rt part of a patch covering both cfe and compiler-rt.
Differential Revision: https://reviews.llvm.org/D40295
llvm-svn: 321518
FDRLoggingTest::MultiThreadedCycling uses std::array so we need to
include the right C++ header and not rely on transitive dependencies.
llvm-svn: 321485
As reported in PR35739, rL252927 added the Windows specific chkstk and
chkstk2 sources unconditionally, and since these are assembly without a
NO_EXEC_STACK_DIRECTIVE at the end, automated vulnerability scanners
warned about the objects having an executable stack.
Avoid the problem by only including these files when Windows is
targeted.
Reviewers: compnerd, rnk, martell
Reviewed By: martell
Subscribers: mstorsjo, mgorny, martell, javed.absar, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41567
llvm-svn: 321431
Summary:
Export aligned new/delete to make dynamic runtimes work again.
Remove all valid new/delete cases from ASan test, there's a test in
common for that.
Reviewers: eugenis
Subscribers: srhines, kubamracek, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41548
llvm-svn: 321394
r318733 introduced a build failure for native MIPS32 systems for xray due
to the lack of __sync_fetch_and_add / __syn_fetch_and_sub support. This patch
extends the existing support providing atomics so that xray can be
successfully built.
The initial patch was reverted in r321292, as I suspected it may have caused the
buildbot failure. Another patch in the updates the bot fetched caused the test
failures which was reverted.
Reviewers: atanasyan, dberris
Differential Revision: https://reviews.llvm.org/D40385
llvm-svn: 321383
Summary:
This patch, on top of https://reviews.llvm.org/D40898, contains the build system
changes necessary to enable the Solaris/x86 sanitizer port.
The only issue of note is the libclang_rt.sancov_{begin, end} libraries: clang relies on the
linker automatically defining __start_SECNAME and __stop_SECNAME labels for
sections whose names are valid C identifiers. This is a GNU ld extension not present
in the ELF gABI, also implemented by gold and lld, but not by Solaris ld. To work around
this, I automatically link the sancov_{begin,end} libraries into every executable for now.
There seems to be now way to build individual startup objects like crtbegin.o/crtend.o,
so I've followed the lead of libclang_rt.asan-preinit which also contains just a single
object.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, kubamracek, mgorny, fedor.sergeev, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40899
llvm-svn: 321373
Summary:
Providing aligned new/delete implementations to match ASan.
Unlike ASan, MSan and TSan do not perform any additional checks
on overaligned memory, hence no sanitizer specific tests.
Reviewers: eugenis
Subscribers: kubamracek, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41532
llvm-svn: 321365
The public sanitizer headers are intended to be usable from either
C++ or C, but they declare no-argument functions with the syntax that
is not a proper prototype declaration in C. This goes unnoticed until
someone uses -Wsystem-headers.
Patch By: mcgrathr
Reviewers: phosek, vitalybuka
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D41475
llvm-svn: 321305
r318733 introduced a build failure for native MIPS32 systems for xray due
to the lack of __sync_fetch_and_add / __syn_fetch_and_sub support. This patch
extends the existing support providing atomics so that xray can be
successfully built.
Reviewers: atanasyan, dberris
Differential Revision: https://reviews.llvm.org/D40385
llvm-svn: 321260
Summary: Very similar to AddressSanitizer, with the exception of the error type encoding.
Reviewers: kcc, alekseyshl
Subscribers: cfe-commits, kubamracek, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D41417
llvm-svn: 321203
There could be a situation when a specific DSO was built with FORTIFY_SOURCE option. In case asan-ed binary link against that DSO,
libasan can't handle the possible memory error because it does not have interceptors for spinrtf_chk, snprintf_chk, vprintf_chk,
vsnprintf_chk, __fprintf_chk functions. Let's interceptors for them.
Patch by Denis Khalikov.
Differential Revision: https://reviews.llvm.org/D40951
llvm-svn: 320990
At least <http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android/
builds/6013/steps/annotate/logs/stdio> complains about
__ubsan::__ubsan_handle_function_type_mismatch_abort (compiler-rt
lib/ubsan/ubsan_handlers.cc) returning now despite being declared 'noreturn', so
looks like a different approach is needed for the function_type_mismatch check
to be called also in cases that may ultimately succeed.
llvm-svn: 320981
As discussed in the mail thread <https://groups.google.com/a/isocpp.org/forum/
#!topic/std-discussion/T64_dW3WKUk> "Calling noexcept function throug non-
noexcept pointer is undefined behavior?", such a call should not be UB.
However, Clang currently warns about it.
There is no cheap check whether two function type_infos only differ in noexcept,so pass those two type_infos as additional data to the function_type_mismatch
handler (with the optimization of passing a null "static callee type" info when that is already noexcept, so the additional check can be avoided anyway). For
the Itanium ABI (which appears to be the only one that happens to be used on
platforms that support -fsanitize=function, and which appears to only record
noexcept information for pointer-to-function type_infos, not for function
type_infos themselves), we then need to check the mangled names for occurrence
of "Do" representing "noexcept".
This is the compiler-rt part of a patch covering both cfe and compiler-rt.
Differential Revision: https://reviews.llvm.org/D40720
llvm-svn: 320977
Summary:
https://reviews.llvm.org/D41121 broke the FreeBSD build due to that type not
being defined on FreeBSD. As far as I can tell, it is an int, but I do not have
a way to test the change.
Reviewers: alekseyshl, kparzysz
Reviewed By: kparzysz
Subscribers: kparzysz, emaste, kubamracek, krytarowski, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41325
llvm-svn: 320931
Summary:
Hook on -DKERNEL_USE (which is also used in lib/builtins) to not import
strlen and not rely on write() being implemented with the stderr on fd 2.
With this, the only requirements to use this library are:
- "Good enough" std::atomic<void*> and std::atomic<int>
- abort() being implemented
- ubsan_message(const char*) being implemented
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39791
llvm-svn: 320831
Summary:
This patch adds a new install target `install-compilert-rt-headers`,
that is similar to `install-clang-headers`.
It allows to install the headers without installing all of
compiler-rt.
Reviewers: alekseyshl, beanz
Reviewed By: beanz
Subscribers: smeenai, beanz, mgorny, #sanitizers, kcc, llvm-commits
Differential Revision: https://reviews.llvm.org/D41244
llvm-svn: 320808
Summary:
The initial implementation used an ASan like Chunk class that was deriving from
a Header class. Due to potential races, we ended up working with local copies
of the Header and never using the parent class fields. ScudoChunk was never
constructed but cast, and we were using `this` as the pointer needed for our
computations. This was meh.
So we refactored ScudoChunk to be now a series of static functions within the
namespace `__scudo::Chunk` that take a "user" pointer as first parameter (former
`this`). A compiled binary doesn't really change, but the code is more sensible.
Clang tends to inline all those small function (in -O2), but GCC left a few not
inlined, so we add the `INLINE` keyword to all.
Since we don't have `ScudoChunk` pointers anymore, a few variables were renamed
here and there to introduce a clearer distinction between a user pointer
(usually `Ptr`) and a backend pointer (`BackendPtr`).
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41200
llvm-svn: 320745
Summary:
This is the first mostly working version of the Sanitizer port to 32-bit Solaris/x86.
It is currently based on Solaris 11.4 Beta.
This part was initially developed inside libsanitizer in the GCC tree and should apply to
both. Subsequent parts will address changes to clang, the compiler-rt build system
and testsuite.
I'm not yet sure what the right patch granularity is: if it's profitable to split the patch
up, I'd like to get guidance on how to do so.
Most of the changes are probably straightforward with a few exceptions:
* The Solaris syscall interface isn't stable, undocumented and can change within an
OS release. The stable interface is the libc interface, which I'm using here, if possible
using the internal _-prefixed names.
* While the patch primarily target 32-bit x86, I've left a few sparc changes in. They
cannot currently be used with clang due to a backend limitation, but have worked
fine inside the gcc tree.
* Some functions (e.g. largefile versions of functions like open64) only exist in 32-bit
Solaris, so I've introduced a separate SANITIZER_SOLARIS32 to check for that.
The patch (with the subsequent ones to be submitted shortly) was tested
on i386-pc-solaris2.11. Only a few failures remain, some of them analyzed, some
still TBD:
AddressSanitizer-i386-sunos :: TestCases/Posix/concurrent_overflow.cc
AddressSanitizer-i386-sunos :: TestCases/init-order-atexit.cc
AddressSanitizer-i386-sunos :: TestCases/log-path_test.cc
AddressSanitizer-i386-sunos :: TestCases/malloc-no-intercept.c
AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/concurrent_overflow.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/start-deactivated.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/default_options.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/init-order-atexit.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/log-path_test.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/malloc-no-intercept.c
SanitizerCommon-Unit :: ./Sanitizer-i386-Test/MemoryMappingLayout.DumpListOfModules
SanitizerCommon-Unit :: ./Sanitizer-i386-Test/SanitizerCommon.PthreadDestructorIterations
Maybe this is good enough the get the ball rolling.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, jyknight, kubamracek, krytarowski, fedor.sergeev, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40898
llvm-svn: 320740
This includes a few nice bits of refactoring (e.g splitting out the
exclusive locking code into a common utility).
Hopefully the Windows support is fixed now.
Patch by Rainer Orth!
Differential Revision: https://reviews.llvm.org/D40944
llvm-svn: 320731
Petr Hosek