This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Disable coverage with sanitize-coverage=0
ClosedPublic

Authored by bungeman on Dec 20 2021, 12:12 PM.

Details

Reviewers
ldionne
phosek
Group Reviewers
Restricted Project
Restricted Project
Restricted Project
Commits
rGfb1582f6c544: [libc++] Disable coverage with sanitize-coverage=0
Summary

When building libcxx, libcxxabi, and libunwind the build environment may
specify any number of sanitizers. For some build feature tests these
sanitizers must be disabled to prevent spurious linking errors. With
-fsanitize= this is straight forward with -fno-sanitize=all. With
-fsanitize-coverage= there is no -fno-sanitize-coverage=all, but there
is the equivalent undocumented but tested -fsanitize-coverage=0.

The current build rules fail to disable 'trace-pc-guard'. By disabling
all sanitize-coverage flags, including 'trace-pc-guard', possible
spurious linker errors are prevented. In particular, this allows libcxx,
libcxxabi, and libunwind to be built with HonggFuzz.

CMAKE_REQUIRED_FLAGS is extra compile flags when running CMake build
configuration steps (like check_cxx_compiler_flag). It does not affect
the compile flags for the actual build of the project (unless of course
these flags change whether or not a given source compiles and links or
not). So libcxx, libcxxabi, and libunwind will still be built with any
specified sanitize-coverage as before. The build configuration steps
(which are mostly checking to see if certain compiler flags are
available) will not try to compile and link "int main() { return 0;}"
(or other specified source) with sanitize-coverage (which can fail to
link at this stage in building, since the final compile flags required
are yet to be determined).

The change to LIBFUZZER_CFLAGS was done to keep it consistent with the
obvious intention of disabling all sanitize-coverage. This appears to
be intentional, preventing the fuzzer driver itself from showing up in
any coverage calculations.

Diff Detail

Event Timeline

bungeman created this revision.Dec 20 2021, 12:12 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 20 2021, 12:12 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
bungeman requested review of this revision.Dec 20 2021, 12:12 PM
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptDec 20 2021, 12:12 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added a subscriber: Restricted Project. · View Herald Transcript
ldionne requested changes to this revision.Dec 21 2021, 7:03 AM
ldionne added a subscriber: ldionne.

I'm not super familiar with -fsanitize-coverage, but I don't understand why this change is correct. Why is it correct to go from excluding edge,trace-cmp,indirect-calls,8bit-counters from -fsanitize-coverage to excluding everything? Aren't we basically losing the ability to generate coverage information?

This revision now requires changes to proceed.Dec 21 2021, 7:03 AM

-fsanitize-coverage was introduced in D31639 (CC @phosek).

At a glance, the intention might to catch layering issue (libc++abi is very low, a runtime library using libc++abi used by libc++abi may be problematic). For many -fsanitize-coverage=, AIUI the __sanitizer_cov_* hooks are provided by the user. If the user hooks use C++, the layering may be weird.

Thanks for the background @MaskRay. I will let @phosek take a look at this, if he's fine with it, I am too.

Perhaps the commit comment could have been a bit more detailed.

CMAKE_REQUIRED_FLAGS is extra compile flags when running CMake build configuration steps (like check_cxx_compiler_flag). It does not affect the compile flags for the actual build of the project (unless of course these flags change whether or not a given source compiles and links or not). So libcxx, libcxxabi, and libunwind would still be built with any specified sanitize-coverage as before. The build configuration steps (which are mostly checking to see if certain compiler flags are available) will not try to compile and link int main() { return 0;} (or other specified source) with sanitize-coverage (which can fail to link at this stage in building, since the final compile flags required are yet to be determined).

The change to LIBFUZZER_CFLAGS was done to keep it consistent with the obvious intention of disabling all sanitize-coverage. This appears to be intentional, preventing the fuzzer driver itself from showing up in any coverage calculations. This is somewhat less important for my use case, but it seemed a good idea to update all of these.

ldionne accepted this revision.Jan 3 2022, 6:28 AM

LGTM but please update the commit message with the info in your last comment. Thanks!

This revision is now accepted and ready to land.Jan 3 2022, 6:28 AM
phosek accepted this revision.Jan 4 2022, 2:18 PM

LGTM

bungeman edited the summary of this revision. (Show Details)Jan 5 2022, 7:29 AM
bungeman updated this revision to Diff 397583.Jan 5 2022, 7:39 AM

Add additional explanation to commit message.

After reading through the contribution doc again, it looks like I need to mention here that I don't have commit access and so will need someone to commit this on my behalf.

Add additional explanation to commit message.

I guess we can't see update in patch description if it's in local git commit.
Can you make sure that Review summary above includes the update?

After reading through the contribution doc again, it looks like I need to mention here that I don't have commit access and so will need someone to commit this on my behalf.

Unless any other volunteers, I will land the patch later today.

Add additional explanation to commit message.

I guess we can't see update in patch description if it's in local git commit.
Can you make sure that Review summary above includes the update?

I've made sure that the Review summary on this page and the commit message of the latest patch are the same and include the additional explanation (the last two paragraphs).

This revision was landed with ongoing or failed builds.Jan 7 2022, 5:53 PM
This revision was automatically updated to reflect the committed changes.