| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-noexcept pointer in C++17
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
|
|
|
|
|
|
|
|
| |
This is paired with the clang change: https://reviews.llvm.org/D40698
Differential Revision: https://reviews.llvm.org/D40700
llvm-svn: 321232
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function through non-noexcept pointer in C++17"
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-noexcept pointer in C++17
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
|
|
|
|
| |
llvm-svn: 320129
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
not work.
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
|
|
|
|
|
|
| |
I think it got accidentally enabled in r315105 or thereabouts.
llvm-svn: 315374
|
|
|
|
|
|
| |
MAP_FIXED discards the existing mapping at the given address.
llvm-svn: 315247
|
|
|
|
| |
llvm-svn: 315220
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: vitalybuka
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D38527
llvm-svn: 315010
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D37598
llvm-svn: 313097
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D34591
llvm-svn: 309461
|
|
|
|
| |
llvm-svn: 309042
|
|
|
|
|
| |
See: https://bugs.llvm.org/show_bug.cgi?id=33881
llvm-svn: 309008
|
|
|
|
|
|
|
|
| |
(compiler-rt)
Compiler-rt changes associated with: D34121
llvm-svn: 307956
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D34298
llvm-svn: 306164
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Compiler-rt part of: https://reviews.llvm.org/D33910
Differential Revision: https://reviews.llvm.org/D33911
llvm-svn: 305217
|
|
|
|
|
|
|
|
| |
Patch by John Regehr and Will Dietz!
Differential Revision: https://reviews.llvm.org/D20323
llvm-svn: 304461
|
|
|
|
|
|
| |
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_check/32035
llvm-svn: 304440
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
lit would interpret the exit code as failuire.
llvm-svn: 303809
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Some problems with ARM stack unwinding led to inaccurate stack traces being
printed, which caused this test to fail on
http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh
llvm-svn: 302239
|
|
|
|
|
|
| |
Patch by Max Moroz, reviewed at https://reviews.llvm.org/D32542
llvm-svn: 302218
|
|
|
|
| |
llvm-svn: 302211
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 301589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 298539
|
|
|
|
| |
llvm-svn: 298117
|
|
|
|
| |
llvm-svn: 295995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
allocator
llvm-svn: 279661
|
|
|
|
|
|
| |
Also replace mkdir -p with rm -rf && mkdir.
llvm-svn: 272839
|
|
|
|
|
|
|
| |
By default coverage is dumped to the current directory, which may not
always be writable.
llvm-svn: 272732
|
|
|
|
| |
llvm-svn: 272718
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This CL adds a weak check for a Vtable prefix: for a well-formed
Vtable, we require the prefix to be within [-1<<20; 1<<20].
Practically, this solves most of the known cases when UBSan segfaults
without providing any useful diagnostics.
Reviewers: pcc
Subscribers: kubabrecka
Differential Revision: http://reviews.llvm.org/D19750
llvm-svn: 271560
|
|
|
|
|
|
|
| |
After r270775, Clang is smarter about the generating the locations for
member-function calls. Update some ubsan tests accordingly.
llvm-svn: 270801
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18845
llvm-svn: 265614
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That change did:
-#if defined(__BIG_ENDIAN__)
+#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
If __BYTE_ORDER__ and __ORDER_BIG_ENDIAN__ aren't defined, like
they are with MSVC, this condition is true (0 == 0).
Fixes PR26919.
llvm-svn: 263324
|