测量翻译为 C/C++ 的自定义编程语言文件的测试覆盖率?
我有领域特定语言 (DSL) 的代码。这种语言中的文件被翻译成 C 源代码文件,然后由常用的编译器工具链 (GCC) 编译成二进制文件:
DSL file --> C file --> Object file --> binary file
我想测量用这种 DSL 编写的代码的测试覆盖率。该语言缺乏用于测量测试覆盖率的本机工具支持。不过,我可以使用传统的 GCC 工具(例如 gcov
)和编译器的 --coverage
标志(或 Clang 等效项)来检测生成的二进制文件。然后可以使用覆盖信息对中间 C 表示进行注释。
DSL file --> C file --> Instrumented object file --> instrumented binary file --> coverage database
↕ |
annotated C file <-----------------------------------------------------------+
问题是,中间 C 代码没有精确映射到其 DSL 输入:符号可能被重命名、方法可能会移动、添加和删除行等。
在心里来回映射源代码行是相当困难的。
有没有办法追溯收集到的覆盖范围信息,并将其与原始 DSL 代码关联起来?
I have code in a domain-specific language (DSL). Files in this language are translated into C source code files, which are then compiled into binaries by a usual compiler toolchain (GCC):
DSL file --> C file --> Object file --> binary file
I want to measure test coverage for code written in this DSL. The language lacks native tooling support for measuring test coverage. However, I can use traditional GCC tools such as gcov
and compiler's --coverage
flags (or Clang equivalents) to instrument the generated binaries. The intermediate C-representation can then be annotated with coverage information.
DSL file --> C file --> Instrumented object file --> instrumented binary file --> coverage database
↕ |
annotated C file <-----------------------------------------------------------+
The problem is, the intermediate C-code does not precisely map to its DSL input: symbols may be renamed, methods moved around, lines added and removed etc.
It is quite hard to mentally map the source code lines back and forth.
Is there a way to trace back collected coverage information to associate it with the original DSL code?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
事实证明,
gcovr
(我假设它包装的gcov
也能做到这一点)理解#line
预处理器指令。该指令通知后面的代码行应被视为来自不同名称的源文件并放置在不同的行号处。因此,只要我的 DSL 到 C 转换器能够使用
#line
注释生成的代码,如下所示,覆盖率工具就能够将覆盖率数据库与原始 DSL 代码关联起来:It turns out that
gcovr
(and I assumegcov
which it wraps does it as well) understands#line
preprocessor directives. This directive informs that code lines following it should be treated as if they came from a differently named source file and were placed at different line number.So as long as my DSL-to-C translator is capable to annotate the generated code with
#line
s as shown below, the coverage tools are capable of associating the coverage database with the original DSL code: