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

1 files changed, 13 insertions, 23 deletions

diff --git a/clang/docs/ControlFlowIntegrity.rst b/clang/docs/ControlFlowIntegrity.rst
index eed5ac51200..c403610952c 100644
--- a/clang/docs/ControlFlowIntegrity.rst
+++ b/clang/docs/ControlFlowIntegrity.rst
@@ -25,25 +25,13 @@ As currently implemented, all schemes rely on link-time optimization (LTO);
 so it is required to specify ``-flto``, and the linker used must support LTO,
 for example via the `gold plugin`_.
 
-To allow the checks to be implemented efficiently, the program must
-be structured such that certain object files are compiled with CFI
+To allow the checks to be implemented efficiently, the program must be
+structured such that certain object files are compiled with CFI
 enabled, and are statically linked into the program. This may preclude
-the use of shared libraries in some cases.
-
-The compiler will only produce CFI checks for a class if it can infer hidden
-LTO visibility for that class. LTO visibility is a property of a class that
-is inferred from flags and attributes. For more details, see the documentation
-for :doc:`LTO visibility <LTOVisibility>`.
-
-The ``-fsanitize=cfi-{vcall,nvcall,derived-cast,unrelated-cast}`` flags
-require that a ``-fvisibility=`` flag also be specified. This is because the
-default visibility setting is ``-fvisibility=default``, which would disable
-CFI checks for classes without visibility attributes. Most users will want
-to specify ``-fvisibility=hidden``, which enables CFI checks for such classes.
-
-Experimental support for :ref:`cross-DSO control flow integrity
-<cfi-cross-dso>` exists that does not require classes to have hidden LTO
-visibility. This cross-DSO support has unstable ABI at this time.
+the use of shared libraries in some cases. Experimental support for
+:ref:`cross-DSO control flow integrity <cfi-cross-dso>` exists that
+does not have these requirements. This cross-DSO support has unstable
+ABI at this time.
 
 .. _gold plugin: http://llvm.org/docs/GoldPlugin.html
 
@@ -245,6 +233,11 @@ A :doc:`SanitizerSpecialCaseList` can be used to relax CFI checks for certain
 source files, functions and types using the ``src``, ``fun`` and ``type``
 entity types.
 
+In addition, if a type has a ``uuid`` attribute and the blacklist contains
+the type entry ``attr:uuid``, CFI checks are suppressed for that type. This
+allows all COM types to be easily blacklisted, which is useful as COM types
+are typically defined outside of the linked program.
+
 .. code-block:: bash
 
     # Suppress checking for code in a file.
@@ -254,6 +247,8 @@ entity types.
     fun:*MyFooBar*
     # Ignore all types in the standard library.
     type:std::*
+    # Ignore all types with a uuid attribute.
+    type:attr:uuid
 
 .. _cfi-cross-dso:
 
@@ -265,11 +260,6 @@ flow integrity mode, which allows all CFI schemes listed above to
 apply across DSO boundaries. As in the regular CFI, each DSO must be
 built with ``-flto``.
 
-Normally, CFI checks will only be performed for classes that have hidden LTO
-visibility. With this flag enabled, the compiler will emit cross-DSO CFI
-checks for all classes, except for those which appear in the CFI blacklist
-or which use a ``no_sanitize`` attribute.
-
 Design
 ======