1

我正在尝试bazel coverage //my:test输出覆盖数据文件，使用自定义 C 规则构建并使用自定义 clang 工具链。

对于 Bazel 的原生 C 规则，这是一个已解决的问题。cc_library我可以使用和原生规则构建覆盖输出，方法cc_test是运行以下命令并设置 env：

export BAZEL_USE_LLVM_NATIVE_COVERAGE=1
export GCOV=/path/to/llvm-profdata
export BAZEL_LLVM_COV=/path/to/llvm-cov
export CC=/path/to/clang

bazel coverage //my:test --experimental_generate_llvm_lcov --combined_report=lcov

测试目标有一个coverage.dat文件输出，也有一个组合的 dat 报告文件。我注意到cc_library目标返回一个InstrumentedFilesInfo提供程序，该提供程序具有在编译期间填充了文件输出的“元数据文件”属性。.gcno

我正在使用cc_commonStarlark 库来构建自定义 C 规则，并且我的编译操作是通过cc_common.compile(). 虽然*.gcno文件是 Bazel 期望从此操作 [0] 输出的输出，但 compile 函数不会*.gcno File在编译上下文或编译输出中返回任何对象，因此将它们用作另一个操作的输入/在提供程序中返回/添加到目标的运行文件是不可能。

我知道这些.dat文件是使用*.gcno编译输出和*.gcda沙盒测试执行输出生成的，并结合在collect_cc_coverage.sh脚本中。在我的规则实现的管道中缺少某些东西，无法通过返回由构造的提供程序来修复，coverage_common.instrumented_files_info()并声明额外的输出cc_common.compile()目前是不可能的。

[0]：在添加文件的地方运行coverage而不是test具有工具链功能，输出文件并出现在.--compile.gcnobazel-out

我的问题：

  • 有没有人有为自定义 C 规则实现代码覆盖的经验？
  • 如何让我的测试可执行文件接收.gcno文件、生成.gcda文件并使用我的工具链将两者结合起来生成.dat符合原生 C 规则的文件？（这个问题不需要.gcno- 涉及 profraw/profdata 的解决方案同样有效。）
4

0 回答 0