GCOV和GCOVR:编译后生成否.GCNO文件
我正在尝试在Windows系统中的单元测试项目中获得代码覆盖率。
描述
使用 -fprofile-arcs -ftest-Coverage
编译后,我发现执行文件已生成并正常工作。但是,文件夹中没有任何.gcno文件。因此,我无法通过GCOVR正确输出覆盖范围报告。
软件版本
GCC 8.1.0/gcov 8.1.0/gcovr 5.1/python 3.10.2
步骤
这是我在整个过程中所做的。如果有问题,请帮助我。
-
一个文件夹中只有.c和.h文件
- 使用GCC 编译我的项目
GCC -WALL -WNO -INKNOWN -PRAGMAS -FCOMPARE -DEBUG -SECOND -FPROFILE -ARCS -FTEST -COVERAGE -DUTEST.C CUTEST.C bzr2.c bzr2.c bzr2.c bzr2_test.c -o beta.c -o beta.exe.c -o beta.exe
-
然后我在文件夹中得到了beta.exe。
-
运行beta.exe后,我的测试结果(所有测试均已通过。)在命令行窗口中显示。此外,还有.gcda文件,带有与我的.c文件相同的文件名。
-
然后我运行
gcovr -r。
,结果如下所示。我认为为什么GCOVR无法显示覆盖范围信息的环境是编译我的项目后没有生成的.gcno文件。但是我不明白为什么以及如何解决这个问题。
------------------------------------------------------------------------------
GCC Code Coverage Report
Directory: .
------------------------------------------------------------------------------
File Lines Exec Cover Missing
------------------------------------------------------------------------------
------------------------------------------------------------------------------
TOTAL 0 0 --%
------------------------------------------------------------------------------
感谢您的时间!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
删除
-fcompare-debug-second
选项。它用于调试编译器本身,并导致编译器(请参阅:)
创建GCNO文件是如此副作用。
一般提示:
代替
-fprofile-arcs -test-coverage
您可以简单地使用- coverage
选项。当您一口气编译多个源文件时,GCC试图找出中间文件的文件名,并自动为诸如GCNO文件(例如GCNO文件)派生一些名称。至少在
为了单独编译所有文件,我们将使用结构:
在这一点上,使用构建系统通常是合适的,例如,通过编写makefile:
Remove the
-fcompare-debug-second
option. It is used for debugging the compiler itself, and causes the compiler(see: https://gcc.gnu.org/onlinedocs/gcc-8.5.0/gcc/Developer-Options.html)
Creation of gcno files is such a side effect.
General tips:
Instead of
-fprofile-arcs -test-coverage
you can simply use the--coverage
option.When you compile multiple source files in one go, then GCC tries to figure out file names for intermediate files, and also automatically derives some name for secondary outputs like gcno files. This used to be somewhat unintuitive, at least until reasonable behaviour was implemented in GCC 11.
To compile all of the files individually, we would use the structure:
At this point, it's typically appropriate to use a build system, for example by writing a Makefile: