Commit Graph

9 Commits

Author SHA1 Message Date
Peter Collingbourne 3afb266886 Re-apply r267784, r267824 and r267830.
I have updated the compiler-rt tests.

llvm-svn: 267903
2016-04-28 17:09:37 +00:00
Benjamin Kramer 5556a5cf3b Revert r267784, r267824 and r267830.
It makes compiler-rt tests fail if the gold plugin is enabled.

Revert "Rework interface for bitset-using features to use a notion of LTO visibility."
Revert "Driver: only produce CFI -fvisibility= error when compiling."
Revert "clang/test/CodeGenCXX/cfi-blacklist.cpp: Exclude ms targets. They would be non-cfi."

llvm-svn: 267871
2016-04-28 12:14:47 +00:00
Peter Collingbourne a8b2f7c0d7 Rework interface for bitset-using features to use a notion of LTO visibility.
Bitsets, and the compiler features they rely on (vtable opt, CFI),
only have visibility within the LTO'd part of the linkage unit. Therefore,
only enable these features for classes with hidden LTO visibility. This
notion is based on object file visibility or (on Windows)
dllimport/dllexport attributes.

We provide the [[clang::lto_visibility_public]] attribute to override the
compiler's LTO visibility inference in cases where the class is defined
in the non-LTO'd part of the linkage unit, or where the ABI supports
calling classes derived from abstract base classes with hidden visibility
in other linkage units (e.g. COM on Windows).

If the cross-DSO CFI mode is enabled, bitset checks are emitted even for
classes with public LTO visibility, as that mode uses a separate mechanism
to cause bitsets to be exported.

This mechanism replaces the whole-program-vtables blacklist, so remove the
-fwhole-program-vtables-blacklist flag.

Because __declspec(uuid()) now implies [[clang::lto_visibility_public]], the
support for the special attr:uuid blacklist entry is removed.

Differential Revision: http://reviews.llvm.org/D18635

llvm-svn: 267784
2016-04-27 20:39:53 +00:00
Evgeniy Stepanov f31ea30694 [cfi] Safe handling of unaddressable vtable pointers (clang).
Avoid crashing when printing diagnostics for vtable-related CFI
errors. In diagnostic mode, the frontend does an additional check of
the vtable pointer against the set of all known vtable addresses and
lets the runtime handler know if it is safe to inspect the vtable.

http://reviews.llvm.org/D16823

llvm-svn: 259716
2016-02-03 22:18:55 +00:00
Peter Collingbourne 574975efa9 CodeGen: Only emit CFI unrelated cast checks for bit casts.
We were previously emitting them for no-op casts (e.g. implicit casts
to const).

llvm-svn: 257738
2016-01-14 02:49:48 +00:00
Peter Collingbourne 2c7f7e31c4 CFI: Introduce -fsanitize=cfi-icall flag.
This flag causes the compiler to emit bit set entries for functions as well
as runtime bitset checks at indirect call sites. Depends on the new function
bitset mechanism.

Differential Revision: http://reviews.llvm.org/D11857

llvm-svn: 247238
2015-09-10 02:17:40 +00:00
Peter Collingbourne ee381ffba4 CodeGen: Add CFI unrelated cast checks to the new pointer code path.
llvm-svn: 247105
2015-09-09 00:01:31 +00:00
Peter Collingbourne 6708c4a176 Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag.
This causes programs compiled with this flag to print a diagnostic when
a control flow integrity check fails instead of aborting. Diagnostics are
printed using UBSan's runtime library.

The main motivation of this feature over -fsanitize=vptr is fidelity with
the -fsanitize=cfi implementation: the diagnostics are printed under exactly
the same conditions as those which would cause -fsanitize=cfi to abort the
program. This means that the same restrictions apply regarding compiling
all translation units with -fsanitize=cfi, cross-DSO virtual calls are
forbidden, etc.

Differential Revision: http://reviews.llvm.org/D10268

llvm-svn: 240109
2015-06-19 01:51:54 +00:00
Peter Collingbourne d2926c91d5 Implement bad cast checks using control flow integrity information.
This scheme checks that pointer and lvalue casts are made to an object of
the correct dynamic type; that is, the dynamic type of the object must be
a derived class of the pointee type of the cast. The checks are currently
only introduced where the class being casted to is a polymorphic class.

Differential Revision: http://reviews.llvm.org/D8312

llvm-svn: 232241
2015-03-14 02:42:25 +00:00