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

【问题标题】：How to do code coverage on embedded如何在嵌入式上进行代码覆盖
【发布时间】：2012-01-23 19:14:26
【问题描述】：

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

【问题讨论】：

代码覆盖在嵌入式系统上不太常见。但是为您的问题提供一个好的答案需要有关您的系统的更多详细信息。什么CPU？什么操作系统？什么编译器工具链？
你只需要写函数还是读写函数？如果只是写（打开、关闭、写），您可以创建自己的，也许将写输出发送到串行端口，以便在其他地方存储/记录。
是否可以在可以使用覆盖选项的系统上编译和运行测试？

【解决方案1】：

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

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

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

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

【讨论】：

【解决方案2】：

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

由于嵌入式系统有其自身的、特殊的和广泛变化的需求，因此代码覆盖率的“最佳”解决方案也千差万别。

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

当然还有很多不同风格的代码覆盖：函数、语句、决策/分支、MC/DC

【讨论】：

【解决方案3】：

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

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

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

【讨论】：

【解决方案4】：

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

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

看看我的博文——我描述得很详细。

【讨论】：