coverage-analysis

Build a separate binary with coverage instrumentation flags like -fprofile-instr-generate -fcoverage-mapping for Clang, run it against your fuzzing corpus, then merge profile data with llvm-profdata and generate reports with llvm-cov.

Install the nightly toolchain with llvm-tools-preview, then run cargo +nightly fuzz coverage <target>. Use cargo cov with rustfilt demangling to produce HTML reports filtered to your crate's source files.

Use dedicated coverage tools like llvm-cov or gcovr for reproducible measurements. Different fuzzers calculate internal coverage differently, making cross-tool comparisons based on fuzzer statistics meaningless.

A crashing corpus input terminates the execution runtime before profile data is written. Fix crashes first, or fork a child process per input so crashes are isolated and coverage for remaining inputs is preserved.

No, fuzzer instrumentation like -fsanitize=fuzzer or afl-clang-fast conflicts with profile instrumentation. Build a separate binary with standard Clang or GCC coverage flags while reusing the same harness function.

Skip it when the campaign is actively finding crashes, coverage infrastructure is not set up, or the codebase is so large that full reports are impractical. Fuzzer-internal metrics may suffice in those cases.