8

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

4

4 回答 4

9

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

如果您没有硬件支持，您可能不得不求助于仿真。许多工具链包括一个指令级模拟器，它将执行跟踪、代码覆盖和分析，但您可能必须创建调试脚本或代码存根来模拟硬件以强制执行所有路径。

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

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

于 2011-12-20T19:37:51.570 回答
2

免责声明：我工作的公司（Rapita Systems）提供针对嵌入式应用程序的代码覆盖解决方案。

因为嵌入式系统有它们自己的、特殊的和广泛变化的要求，所以代码覆盖的“最佳”解决方案也千差万别。

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

当然，还有许多不同风格的代码覆盖率可供使用：函数、语句、决策/分支、MC/DC

于 2012-01-06T10:21:49.200 回答
0

我们的 C/C++ 测试覆盖工具系列检测源代码，生成您使用嵌入式编译器编译的程序，该程序会将测试覆盖数据收集到添加到程序中的“小”数据结构中。这适用于各种方言，包括 ANSI、GCC、Microsoft 和 GreenHills。

您必须将该数据结构从嵌入式执行上下文导出到 PC 上的文件；这通常很容易通过备用串行或并行端口以及少量特定于您的端口的自定义代码来完成。这些工具将提供测试覆盖视图和结果文件的摘要。

因此，在大多数实际情况下，您可以使用这些工具从嵌入式系统中收集测试覆盖率数据。

于 2011-12-27T04:19:42.720 回答
0

如果基于 GCC 的跨工具链支持您的嵌入式目标，您可能会发现我的博客文章很有用。

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

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

于 2021-05-09T09:13:42.753 回答