我正在建立一个包含几个*.c文件的库，并且在子文件夹test中有一个测试文件。构建工具是CMake，CLang和ninja。它在Windows 10和Unbuntu 16.04上运行。我正在尝试生成代码覆盖率以供查看。
在Unbuntu上，我的CMakeLists.txt包含该行
set(CMAKE_CXX_FLAGS "-g -O0 -Wall -fprofile-arcs -ftest-coverage -fprofile-instr-generate -fcoverage-mapping -pthread")
我不确定这些选项的作用。
编译器生成test.cpp.o和test.cpp.gcno。运行测试程序将生成test.cpp.gcda。
使用这些文件运行llvm-cov原因
llvm-cov show: for the -instr-profile option: must be specified at least once!
我也看到过类似的错误
llvm-cov gcov: Not enough positional command line arguments specified!
我明白USAGE: llvm-cov gcov [options] SOURCEFILE，但从未见过SOURCEFILE的解释或示例。
我有兴趣查看至少使用哪一行代码。我想念什么？
尝试运行llvm-cov gcov * .gcno
这将显示所有源文件的覆盖范围。
-fprofile-arcs添加代码，以便检测程序流弧。在执行期间，程序记录每个分支和调用执行了多少次，以及执行或返回了多少次。在支持优先支持构造函数的目标上，性能分析可以正确处理用作全局变量类型的类的构造函数，析构函数和C ++构造函数（和析构函数）。
当编译的程序退出时，它会将每个源文件的数据保存到一个名为auxname.gcda的文件中。数据可用于配置文件定向的优化（-fbranch-probability）或测试覆盖率分析（-ftest-coverage）。每个目标文件的辅助名称都是从输出文件的名称生成的（如果已明确指定），它不是最终的可执行文件，否则它是源文件的基本名称。在这两种情况下，都删除了任何后缀（例如，输入文件dir / foo.c的foo.gcda或指定为-o dir / foo.o的输出文件的dir / foo.gcda）。请参阅交叉分析。
-覆盖率此选项用于编译和链接为覆盖率分析而准备的代码。该选项是-fprofile-arcs -ftest-coverage（在编译时）和-lgcov（在链接时）的同义词。有关更多选项，请参阅这些选项的文档。
使用-fprofile-arcs以及优化和代码生成选项来编译源文件。对于测试覆盖率分析，请使用附加的-ftest-coverage选项。您不需要分析程序中的每个源文件。使用-fprofile-abs-path额外编译源文件，以在.gcno文件中创建绝对路径名。这使gcov可以在使用不同工作目录进行编译的项目中找到正确的源。用-lgcov或-fprofile-arcs（后者表示前者）链接目标文件。以代表性的工作量运行该程序以生成电弧轮廓信息。可以重复多次。您可以运行程序的并发实例，并且如果文件系统支持锁定，则将正确更新数据文件。除非执行严格的ISO C语言方言，否则将检测到分叉调用并正确处理分叉调用，而无需重复计算。对于配置文件导向的优化，请使用相同的优化和代码生成选项以及-fbranch-probabilities重新编译源文件（请参阅控制优化的选项）。为了进行测试覆盖率分析，请使用gcov从.gcno和.gcda文件生成易于阅读的信息。有关更多信息，请参阅gcov文档。使用-fprofile-arcs，GCC为程序的每个功能创建一个程序流程图，然后为该图找到一个生成树。只需要检测不在生成树上的弧：编译器添加代码以计算这些弧的执行次数。当圆弧是块的唯一出口或唯一入口时，可以将仪表代码添加到块中；否则，必须创建一个新的基本块来保存检测代码。
-ftest-coverage生成一个注释文件，gcov代码覆盖率实用程序（请参阅gcov-测试覆盖率程序）可用于显示程序覆盖率。每个源文件的注释文件称为auxname.gcno。请参阅上面的-fprofile-arcs选项以获取auxname的描述以及有关如何生成测试coverage数据的说明。如果不进行优化，覆盖率数据将与源文件更紧密地匹配。