如何在嵌入式代码上进行代码覆盖

时间:2011-12-19 17:26:42

标签: embedded code-coverage gcov

我为非POSIX嵌入式系统编写项目,所以我不能使用gcc选项--coverage(我没有读或写)。我还能做些什么来产生类似输出的gcov。我有一个输出功能。

3 个答案:

答案 0 :(得分:9)

通过具有嵌入式跟踪的处理器,暴露跟踪端口的电路板设计以及合适的硬件调试器和关联软件,可以最轻松地完成此操作。例如,许多基于Cortex-M的设备都包含ARM的嵌入式跟踪宏单元(ETM),Keil的uVision IDE和ULINK-Pro调试器支持这一功能,以提供代码覆盖和指令/源级跟踪以及实时分析。硬件跟踪的优势在于它是非侵入式的 - 代码可以实时运行。

如果您没有硬件支持,则可能需要使用模拟。许多工具链包括将执行跟踪,代码覆盖和分析的指令级模拟器,但您可能必须创建调试脚本或代码存根来模拟硬件以强制执行所有路径。

第三种方法是在桌面平台上构建代码,使用存根替换目标硬件依赖关系,并对其执行测试和代码覆盖。您必须相信目标C编译器和测试系统编译器都使用相同的语义转换源。这里的优点是可用的调试工具通常优于嵌入式系统可用的调试工具。您还可以在任何硬件可用之前测试大部分代码,并且在大多数情况下执行代码的速度要快得多,可能需要进行更广泛的测试。

没有POSIX API并不排除使用GCC,它只是排除了使用GNU C库。在没有POSIX的嵌入式系统上,使用了替代的C库,例如Newlib。 Newlib有一个系统移植层,用于实现I / O和基本堆管理。

答案 1 :(得分:1)

免责声明:我所工作的公司(Rapita Systems)提供针对嵌入式应用的代码覆盖解决方案。

由于嵌入式系统带来了自己的,特殊的和广泛变化的要求,因此代码覆盖的“最佳”解决方案也有很大差异。

  • 如果您有基于跟踪的设备,例如带有ETM或支持NEXUS的部件的ARM芯片,您可以通过调试器无需仪器即可执行覆盖。
  • 否则,您很可能面临基于仪器的解决方案:
    • 对于RAM限制解决方案,一个好的解决方案是将检测写入I / O端口
    • 或者,您可以将检测记录到RAM缓冲区,并使用各种方法从目标中提取它。

当然还有许多不同类型的代码覆盖:功能,声明,决策/分支,MC / DC

答案 2 :(得分:0)

如果基于 GCC 的跨工具链支持您的嵌入式目标,您可能会发现我的 blog post 很有用。

主要思想是使用适当的 gcov 选项编译代码,然后在内存中创建覆盖信息(最终存储在 .gcda 文件中的内容)。然后,您可以在 GDB 上放置适当的断点,并通过调试链接(串行、JTAG 等)转储此信息。

看看我的博文 - 我非常详细地描述了事情。