[libfuzzer] [clang] Add __has_feature(fuzzing_coverage)

[hctim]

Summary

Probably a useful feature for checking whether a file was built with
-fsanitize=fuzzer or -fsanitize=fuzzer-no-link.

N.B. __has_feature(fuzzing_coverage) doesn't cover instances where users
manually specify -fsanitize-coverage=... (even if the flags are
identical to ToT -fsanitize=fuzzer-no-link). IMHO this is WAI -
-fsanitize=fuzzer-no-link is not a stable set of flags and people that
want sancov for fuzzing should use fuzzer-no-link.

[hctim]

Changed the filename and fixed up the inverted test.

[morehouse]

Can we just use [FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION](https://llvm.org/docs/LibFuzzer.html#fuzzer-friendly-build-mode) instead? I'm a little wary of introducing a new way to do conditional compilation since fuzzers that don't use sancov can't rely on it.

[Dor1s]

What usecase(s) do you have for this in mind?

[hctim]

So - the FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION flag is a property of the build system and not that of the compiler. There are some places (android) where enabling FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION globally changes the behaviour of large amounts of libraries in ways that break the build system.

Having this flag allows us to make targeted compile-time changes to libc based on sancov that don't require enabling FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION across the entire build system.

[morehouse]

In D82926#2125950, @hctim wrote:

So - the FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION flag is a property of the build system and not that of the compiler. There are some places (android) where enabling FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION globally changes the behaviour of large amounts of libraries in ways that break the build system.

Having this flag allows us to make targeted compile-time changes to libc based on sancov that don't require enabling FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION across the entire build system.

Shouldn't we be fixing the fuzzing build for Android then? FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION is what we use everywhere else, so I don't like the idea of making a new flag.

[Dor1s]

If we still decide to proceed with this, would it make sense to expand it to sanitizer_coverage based on any sancov instrumentation being enabled? As you mentioned in the description, there might be users who manually enable certain sancov flags. I think it's good to be able to support those usecases too (e.g. other fuzzing engines).

clang/include/clang/Basic/Features.def

FEATURE(leak_sanitizer,
         LangOpts.Sanitize.has(SanitizerKind::Leak))
 FEATURE(hwaddress_sanitizer,
         LangOpts.Sanitize.hasOneOf(SanitizerKind::HWAddress |
                                    SanitizerKind::KernelHWAddress))
 FEATURE(memtag_sanitizer, LangOpts.Sanitize.has(SanitizerKind::MemTag))
 FEATURE(xray_instrument, LangOpts.XRayInstrument)
 FEATURE(undefined_behavior_sanitizer,
         LangOpts.Sanitize.hasOneOf(SanitizerKind::Undefined))
+FEATURE(fuzzing_coverage,
+        LangOpts.Sanitize.hasOneOf(SanitizerKind::Fuzzer |
+                                   SanitizerKind::FuzzerNoLink))
 FEATURE(assume_nonnull, true)
 FEATURE(attribute_analyzer_noreturn, true)
 FEATURE(attribute_availability, true)
 FEATURE(attribute_availability_with_message, true)
 FEATURE(attribute_availability_app_extension, true)
 FEATURE(attribute_availability_with_version_underscores, true)
 FEATURE(attribute_availability_tvos, true)
 FEATURE(attribute_availability_watchos, true)

clang/test/Lexer/has_feature_fuzzing_coverage.cpp

+// RUN: %clang_cc1 -E  %s -o - | FileCheck --check-prefix=CHECK-NONE %s
+// RUN: %clang_cc1 -E -fsanitize=fuzzer %s -o - \
+// RUN:   | FileCheck --check-prefix=CHECK-ENABLED %s
+// RUN: %clang_cc1 -E -fsanitize=fuzzer-no-link %s -o - \
+// RUN:   | FileCheck --check-prefix=CHECK-ENABLED %s
+
+#if __has_feature(fuzzing_coverage)
+int FuzzingCoverageEnabled();
+#else
+int FuzzingCoverageDisabled();
+#endif
+
+// CHECK-NONE: FuzzingCoverageDisabled
+// CHECK-ENABLED: FuzzingCoverageEnabled