I changed the seed slightly, but forgot to run the tests on a 32-bit system, so
tests which hard-code a specific hash value started breaking.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@341240 91177308-0d34-0410-b5e6-96231b3b80d8
The standard says:
[expr.static.cast] p11: "If the prvalue of type “pointer to cv1 B” points to a B
that is actually a subobject of an object of type D, the resulting pointer points
to the enclosing object of type D. Otherwise, the behavior is undefined."
Therefore, the GEP must be inbounds.
This should solve the failure to optimize away a null check shown in PR35909:
https://bugs.llvm.org/show_bug.cgi?id=35909
Differential Revision: https://reviews.llvm.org/D42249
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322950 91177308-0d34-0410-b5e6-96231b3b80d8
The function sanitizer only checks indirect calls through function
pointers. This excludes all non-static member functions (constructor
calls, calls through thunks, etc. all use a separate code path). Don't
emit function signatures for functions that won't be checked.
Apart from cutting down on code size, this should fix a regression on
Linux caused by r313096. For context, see the mailing list discussion:
r313096 - [ubsan] Function Sanitizer: Don't require writable text segments
Testing: check-clang, check-ubsan
Differential Revision: https://reviews.llvm.org/D38913
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315786 91177308-0d34-0410-b5e6-96231b3b80d8
This change will make it possible to use -fsanitize=function on Darwin and
possibly on other platforms. It fixes an issue with the way RTTI is stored into
function prologue data.
On Darwin, addresses stored in prologue data can't require run-time fixups and
must be PC-relative. Run-time fixups are undesirable because they necessitate
writable text segments, which can lead to security issues. And absolute
addresses are undesirable because they break PIE mode.
The fix is to create a private global which points to the RTTI, and then to
encode a PC-relative reference to the global into prologue data.
Differential Revision: https://reviews.llvm.org/D37597
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313096 91177308-0d34-0410-b5e6-96231b3b80d8
Do not sanitize the 'this' pointer of a member call operator for a lambda with
no capture-default, since that call operator can legitimately be called with a
null this pointer from the static invoker function. Any actual call with a null
this pointer should still be caught in the caller (if it is being sanitized).
This reinstates r311589 (reverted in r311680) with the above fix.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@311695 91177308-0d34-0410-b5e6-96231b3b80d8
In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I
did not see the need for the two checks to have separate null checking logic
for the same pointer. I expected the two checks to either always be enabled
together, or to be mutually compatible.
In the mailing list discussion re: r309007 it became clear that that isn't the
case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean,
it's useful to have -fsanitize=vptr emit its own null check. That's what this
patch does: with it, -fsanitize=vptr can be used without -fsanitize=null.
Differential Revision: https://reviews.llvm.org/D36112
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309846 91177308-0d34-0410-b5e6-96231b3b80d8
The instrumentation generated by -fsanitize=vptr does not null check a
user pointer before loading from it. This causes crashes in the face of
UB member calls (this=nullptr), i.e it's causing user programs to crash
only after UBSan is turned on.
The fix is to make run-time null checking a prerequisite for enabling
-fsanitize=vptr, and to then teach UBSan to reuse these run-time null
checks to make -fsanitize=vptr safe.
Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build
Differential Revision: https://reviews.llvm.org/D35735https://bugs.llvm.org/show_bug.cgi?id=33881
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309007 91177308-0d34-0410-b5e6-96231b3b80d8
This is a recommit of r231150, reverted in r231409. Turns out
that -fsanitize=shift-base check implementation only works if the
shift exponent is valid, otherwise it contains undefined behavior
itself.
Make sure we check that exponent is valid before we proceed to
check the base. Make sure that we actually report invalid values
of base or exponent if -fsanitize=shift-base or
-fsanitize=shift-exponent is specified, respectively.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231711 91177308-0d34-0410-b5e6-96231b3b80d8
It's not that easy. If we're only checking -fsanitize=shift-base we
still need to verify that exponent has sane value, otherwise
UBSan-inserted checks for base will contain undefined behavior
themselves.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231409 91177308-0d34-0410-b5e6-96231b3b80d8
-fsanitize=shift is now a group that includes both these checks, so
exisiting users should not be affected.
This change introduces two new UBSan kinds that sanitize only left-hand
side and right-hand side of shift operation. In practice, invalid
exponent value (negative or too large) tends to cause more portability
problems, including inconsistencies between different compilers, crashes
and inadequeate results on non-x86 architectures etc. That is,
-fsanitize=shift-exponent failures should generally be addressed first.
As a bonus, this change simplifies CodeGen implementation for emitting left
shift (separate checks for base and exponent are now merged by the
existing generic logic in EmitCheck()), and LLVM IR for these checks
(the number of basic blocks is reduced).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231150 91177308-0d34-0410-b5e6-96231b3b80d8
Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.
The advantages of the change are that
* The output order is a bit closer to the source order. The change to
test/CodeGenCXX/pod-member-memcpys.cpp is a good example.
* If we decide to deffer more, it will not cause as large changes in the
estcases as it would without this patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226751 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce the following -fsanitize-recover flags:
- -fsanitize-recover=<list>: Enable recovery for selected checks or
group of checks. It is forbidden to explicitly list unrecoverable
sanitizers here (that is, "address", "unreachable", "return").
- -fno-sanitize-recover=<list>: Disable recovery for selected checks or
group of checks.
- -f(no-)?sanitize-recover is now a synonym for
-f(no-)?sanitize-recover=undefined,integer and will soon be deprecated.
These flags are parsed left to right, and mask of "recoverable"
sanitizer is updated accordingly, much like what we do for -fsanitize= flags.
-fsanitize= and -fsanitize-recover= flag families are independent.
CodeGen change: If there is a single UBSan handler function, responsible
for implementing multiple checks, which have different recoverable setting,
then we emit two handler calls instead of one:
the first one for the set of "unrecoverable" checks, another one - for
set of "recoverable" checks. If all checks implemented by a handler have the
same recoverability setting, then the generated code will be the same.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225719 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change makes CodeGenFunction::EmitCheck() take several
conditions that needs to be checked (all of them need to be true),
together with sanitizer kinds these checks are for. This would allow
to split one call into UBSan runtime into several calls in case
different sanitizer kinds would have different recoverability
settings.
Tests should be fixed accordingly, I'm working on it.
Test Plan: regression test suite.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6219
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221716 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds UBSan check to upcasts. Namely, when we
perform derived-to-base conversion, we:
1) check that the pointer-to-derived has suitable alignment
and underlying storage, if this pointer is non-null.
2) if vptr-sanitizer is enabled, and we perform conversion to
virtual base, we check that pointer-to-derived has a matching vptr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219642 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change adds description of globals created by UBSan
instrumentation (UBSan handlers, type descriptors, filenames) to
llvm.asan.globals metadata, effectively "blacklisting" them. This can
dramatically decrease the data section in binaries built with UBSan+ASan,
as UBSan tends to create a lot of handlers, and ASan instrumentation
increases the global size to at least 64 bytes.
Test Plan: clang regression test suite
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits, byoungyoung, kcc
Differential Revision: http://reviews.llvm.org/D4575
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213392 91177308-0d34-0410-b5e6-96231b3b80d8
Because references must be initialized using some evaluated expression, they
must point to something, and a callee can assume the reference parameter is
dereferenceable. Taking advantage of a new attribute just added to LLVM, mark
them as such.
Because dereferenceability in addrspace(0) implies nonnull in the backend, we
don't need both attributes. However, we need to know the size of the object to
use the dereferenceable attribute, so for incomplete types we still emit only
nonnull.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213386 91177308-0d34-0410-b5e6-96231b3b80d8
check using the ubsan runtime) and -fsanitize=local-bounds (for the middle-end
check which inserts traps).
Remove -fsanitize=local-bounds from -fsanitize=undefined. It does not produce
useful diagnostics and has false positives (PR17635), and is not a good
compromise position between UBSan's checks and ASan's checks.
Map -fbounds-checking to -fsanitize=local-bounds to restore Clang's historical
behavior for that flag.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193205 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
UBSan was checking for alignment of the derived class on the pointer to
the base class, before converting. With some class hierarchies, this could
generate false positives.
Added test-case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187948 91177308-0d34-0410-b5e6-96231b3b80d8
base-to-derived casts have undefined behavior if the object is not actually an
instance of the derived type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175078 91177308-0d34-0410-b5e6-96231b3b80d8
bit-patterns which are not valid values for enumerated or boolean types.
These checks are the ubsan analogue of !range metadata.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170108 91177308-0d34-0410-b5e6-96231b3b80d8
checks to enable. Remove frontend support for -fcatch-undefined-behavior,
-faddress-sanitizer and -fthread-sanitizer now that they don't do anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167413 91177308-0d34-0410-b5e6-96231b3b80d8
Tim Northover