Summary:
This patch (on top of the previous two (https://reviews.llvm.org/D40898 and
https://reviews.llvm.org/D40899) complete the compiler-rt side of the the Solaris
sanitizer port.
It contains the following sets of changes:
* For the time being, the port is for 32-bit x86 only, so reject the various tests on
x86_64.
* When compiling as C++, <setjmp.h> resp. <iso/setjmp_iso.h> only declares
_setjmp and _longjmp inside namespace std.
* MAP_FILE is a Windows feature. While e.g. Linux <sys/mman.h> provides a
no-op compat define, Solaris does not.
* test/asan/TestCases/Posix/coverage.cc was initially failing like this:
/vol/gcc/src/llvm/llvm/local/projects/compiler-rt/lib/sanitizer_common/scripts/sancov.py: 4 files merged; 2 PCs total
rm: cannot remove '/var/gcc/llvm/local/projects/compiler-rt/test/asan/I386SunOSConfig/TestCases/Posix/Output/coverage': Invalid argument
Further digging revealed that the rm was trying to remove the running test's working
directory which failed as observed. cd'ing out of the dir before let the test pass.
* Two tests needed a declaration of alloca. I've now copied the existing code from
test/asan/TestCases/alloca_constant_size.cc, but it may be more profitable and
maintainable to have a common testsuite header where such code is collected.
* Similarly, Solaris' printf %p format doesn't include the leading 0x.
* In test/asan/TestCases/malloc-no-intercept.c, I had to undef __EXTENSIONS__
(predefined by clang for no apparent reason) to avoid conflicting declarations
for memalign.
* test/ubsan/TestCases/Float/cast-overflow.cpp has different platform dependent
ways to define BYTE_ORDER and friends. Why not just use __BYTE_ORDER__ and
friends as predefined by clang and gcc?
Patch by Rainer Orth.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, kubamracek, mgorny, krytarowski, fedor.sergeev, JDevlieghere, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40900
llvm-svn: 322635
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
...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
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:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.
This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.
I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.
Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.
Please review carefully, i have not worked with lit/sanitizer tests before.
The original attempt, r319525 was reverted in r319526 due
to the failures in compiler-rt standalone builds.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc
Differential Revision: https://reviews.llvm.org/D39508
llvm-svn: 319575
This reverts commit r319525.
This change has introduced a problem with the Lit tests build for compiler-rt using Gold: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/6047/steps/test%20standalone%20compiler-rt/logs/stdio
llvm-lit: /b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py:101: fatal: unable to parse config file '/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg', traceback: Traceback (most recent call last):
File "/b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py", line 88, in load_from_path
exec(compile(data, path, 'exec'), cfg_globals, None)
File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 37, in <module>
if root.host_os not in ['Linux'] or not is_gold_linker_available():
File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 27, in is_gold_linker_available
stderr = subprocess.PIPE)
File "/usr/lib/python2.7/subprocess.py", line 390, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1024, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
llvm-svn: 319529
Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.
This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.
I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.
Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.
Please review carefully, i have not worked with lit/sanitizer tests before.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc
Differential Revision: https://reviews.llvm.org/D39508
llvm-svn: 319525
If the lookup using RTLD_NEXT failed, the sanitizer runtime library
is later in the library search order than the DSO that we are trying
to intercept, which means that we cannot intercept this function. We
still want the address of the real definition, though, so look it up
using RTLD_DEFAULT.
Differential Revision: https://reviews.llvm.org/D39779
llvm-svn: 317930
This is a very poorly named feature. I think originally it meant to cover linux only, but the use of it in msan
seems to be about any aarch64 platform. Anyway, this change should be NFC on everything except Android.
llvm-svn: 315389
As a follow-up to r315142, this makes it possible to use ubsan with a
static runtime on Darwin. I've also added a new StandaloneStatic testing
configuration so the new setup can be tested.
llvm-svn: 315143
Summary:
Enable check-cfi and check-ubsan on Android.
Check-ubsan includes standalone and ubsan+asan, but not tsan or msan.
Cross-dso cfi tests are disabled for now.
Reviewers: vitalybuka, pcc
Subscribers: srhines, kubamracek, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D38608
llvm-svn: 315105
This was originally broken by r258744 which introduced a weak reference
from ubsan to ubsan_cxx. This reference does not work directly on
Windows because COFF has no direct concept of weak symbols. The fix is
to use /alternatename to create a weak external reference to ubsan_cxx.
Also fix the definition (and the name, so that we drop cached values)
of the cmake flag that controls whether to build ubsan_cxx. Now the
user-controllable flag is always on, and we turn it off internally
depending on whether we support building it.
Differential Revision: https://reviews.llvm.org/D37882
llvm-svn: 313391
Summary:
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, kcc, filcab, fjricci
Reviewed By: fjricci
Subscribers: srhines, kubamracek, mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36483
llvm-svn: 310412
This reverts commit r309042, thereby adding a test for -fsanitize=vptr
functionality without -fsanitize=null. It also removes -fsanitize=null
from another -fsanitize=vptr test.
llvm-svn: 309847
The dynamic type check needs to inspect vtables, but could crash if it
encounters a vtable pointer to inaccessible memory. In the first attempt
to fix the issue (r304437), we performed a memory accessibility check on
the wrong range of memory. This should *really* fix the problem.
Patch by Max Moroz!
Differential Revision: https://reviews.llvm.org/D34215
llvm-svn: 305489
There is can be a situation when vptr is not initializing
by constructor of the object, and has a junk data which should
be properly checked, because c++ standard says:
"if default constructor is not specified
16 (7.3) no initialization is performed."
Patch by Denis Khalikov!
Differential Revision: https://reviews.llvm.org/D33712
llvm-svn: 304437
Add a lit substitution (I chose %gmlt) so that only stack trace tests
get debug info.
We need a lit substition so that this expands to -gline-tables-only
-gcodeview on Windows. I think in the future we should reconsider the
need for -gcodeview from the GCC driver, but for now, this is necessary.
llvm-svn: 303083
This fixes tests that use debug info to check ubsan stack traces. One
was XFAILd on Windows and the other was actively failing for weeks.
llvm-svn: 302924
This commit made ubsan use the fast unwinder. On SystemZ this requires
test cases to be compiled with -mbackchain. That was already done for
asan, but not ubsan. Add the flag for ubsan as well.
llvm-svn: 302562
This makes it possible to get stacktrace info when print_stacktrace=1 on
Darwin (where the slow unwinder is not currently supported [1]). This
should not regress any other platforms.
[1] The thread about r300295 has a relatively recent discusion about
this. We should be able to enable the existing slow unwind functionality
for Darwin, but this needs more testing.
Differential Revision: https://reviews.llvm.org/D32517
llvm-svn: 301839
When using ASan and UBSan together, the common sanitizer tool name is
set to "AddressSanitizer". That means that when a UBSan diagnostic is
printed out, it looks like this:
SUMMARY: AddressSanitizer: ...
This can confuse users. Fix it so that we always use the correct tool
name when printing out UBSan diagnostics.
Differential Revision: https://reviews.llvm.org/D32066
llvm-svn: 300358
The Clang driver on macOS decides the deployment target based on various things, like your host OS version, the SDK version and some environment variables, which makes lit tests pass or fail based on your environment. Let's make sure we run all lit tests with `-mmacosx-version-min=${SANITIZER_MIN_OSX_VERSION}` (10.9 unless overriden).
Differential Revision: https://reviews.llvm.org/D26929
llvm-svn: 288186
Summary:
Turns out that in the case of -fsanitize=null and a virtual call,
the type check was generated *after* reading from vtable, which
causes a non-interpretable segfault. The check has been moved up
in https://reviews.llvm.org/D26559 and this CL adds a test for this case.
Reviewers: pcc
Subscribers: cfe-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D26560
llvm-svn: 287578
The test contains a switch statement in which two of the cases are
tail-merged, with the call to __ubsan_handle_dynamic_type_cache_miss_abort
in the common tail. When tail-merging occurs, the debug location of the
tail is randomly taken from one of the merge inputs. Luckily for the test,
the expected line number in the check is the one which is chosen by the
tail-merge. However, if the switch cases are re-ordered the test will
fail.
This patch disables tail-merge, making the test resilient to changes
in tail-merge, and unblocking review D25742. It does not change the
semantics of the test.
llvm-svn: 285208
Kamil Rytarowski