SanitizerCoverage 是 LLVM 提供的编译时插桩机制，用于运行时收集执行路径信息，本身不生成覆盖率报告，需配合 llvm-cov 或 lcov 等工具解析数据并渲染成 HTML 或 summary 报告。
SanitizerCoverage 是什么，它能生成“覆盖率报告”吗？
SanitizerCoverage 本身不是覆盖率报告工具，它是 LLVM 提供的一组编译时插桩机制，用于在运行时收集代码执行路径信息（比如哪些 basic block、edge 或函数被触发）。它不直接输出 HTML 或 summary 报告——你得靠 llvm-cov 或第三方脚本（如 lcov）来解析生成的覆盖率数据并渲染成可读格式。模糊测试中常用它配合 libFuzzer 或 AFL++ 收集路径覆盖，但“报告”这一步必须手动补全。
如何编译 C++ 代码启用 SanitizerCoverage 插桩
关键在于链接时保留符号和调试信息，并启用正确的插桩级别。默认 -fsanitize-coverage=trace-pc-guard 最常用，兼顾性能与精度；避免用 trace-pc（无 guard 表，无法做跨进程/多 fuzz 实例聚合）。
-
-fsanitize-coverage=trace-pc-guard：生成__sanitizer_cov_trace_pc_guard调用点，配合 runtime guard 数组记录命中状态 -
-g -O2：必须带调试信息（-g），否则llvm-cov无法映射到源码行 -
-fno-omit-frame-pointer：部分覆盖率工具链（如旧版 llvm-cov）依赖 frame pointer 定位函数边界 - 禁用 LTO：
-flto会干扰插桩位置，导致覆盖率漏报，除非你明确用-fsanitize-coverage=trace-pc-guard -fuse-ld=lld -Wl,-plugin-opt=save-temps配合 LLD
clang++ -g -O2 -fno-omit-frame-pointer \ -fsanitize-coverage=trace-pc-guard \ -o target_fuzzer target.cpp -fsanitize=fuzzer
运行后如何提取和转换覆盖率数据
SanitizerCoverage 运行时把覆盖率写入内存中的 __sanitizer_cov_trace_pc_guard_init 初始化的 guard 数组，但不会自动落盘。你需要主动触发 dump，或依赖 fuzzer 自动保存（如 libFuzzer 的 -dump_coverage=1）。
- libFuzzer 场景：加
-dump_coverage=1参数，运行结束后会在当前目录生成coverage.dat（二进制格式） - 自定义程序：调用
__sanitizer_dump_coverage()（需链接compiler-rt，且该函数非稳定 ABI，LLVM 版本间可能变化） - 转换为
llvm-cov可读格式：用llvm-profdata merge -sparse coverage.dat -o default.profdata - 生成报告：
llvm-cov show ./target_fuzzer -instr-profile=default.profdata -show-inlined -Xdemangler=c++filt
注意： coverage.dat 是稀疏格式，不能直接用 xxd 查看；如果看到 ERROR: Failed to load cover，说明 
llvm-profdata 和编译器 LLVM 版本不一致（比如用 clang-16 编译，却用 llvm-profdata-15 解析）。
模糊测试中容易忽略的覆盖率陷阱
覆盖率数字高 ≠ 测试质量好。SanitizerCoverage 在 fuzzing 中尤其容易产生误导：
- 只统计“是否执行过”，不区分执行次数或输入敏感度——一个 crash 输入和一个普通输入对覆盖率贡献相同
- 插桩粒度是 basic block，函数内联后 block 合并，可能导致“看似覆盖了函数”实则只进了某个分支
- 未初始化的 guard 数组（
__sanitizer_cov_trace_pc_guard_init未被调用）会导致全程零覆盖，常见于静态构造函数未触发或main之前就 exit 的场景 - ASan/UBSan 等其他 sanitizer 与 Coverage 共存时，需统一用
-fsanitize=address,coverage，不能分开加，否则插桩逻辑冲突
真正要靠的是把 llvm-cov 输出和 fuzzer 的 corpus/crash 目录交叉比对——比如某个 .cpp 文件显示 90% 行覆盖，但所有 crash 都来自剩下 10% 的边界条件，那这部分才最值得深挖。
