如何在嵌入式上进行代码覆盖 [英] How to do code coverage on embedded

问题描述

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

I write a project for a non POSIX embedded system so I cannot use gcc option --coverage (i don't have read or write). What else can I do to produce gcov like output. I do have an output function.

推荐答案

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

It can be most easily done with by a processor with embedded trace, a board design that exposes the trace port, and a suitable hardware debugger and associate software. For example, many Cortex-M based devices include ARM's embedded trace macrocell (ETM), and this is supported by Keil's uVision IDE and ULINK-Pro debugger to provide code coverage and instruction/source level trace as well as real-time profiling. Hardware trace has the advantage that it is non-intrusive - the code runs in real-time.

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

If you do not have the hardware support, you may have to resort to simulation. Many tool-chains include an instruction level simulator that will perform trace, code-coverage, and profiling, but you may have to create debug scripts or code stubs to simulate hardware to coerce the execution of all paths.

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

A third alternative is to build the code on a desktop platform with stubs to replace target hardware dependencies, and perform testing and code coverage on that. You have to trust that the target C compiler and the test system compiler both translate the source with identical semantics. The advantage here is that the debug tools available are often superior to those available to embedded systems. You can also test much of your code before any hardware is available, and in most cases execute code much faster, possibly allowing more extensive testing.

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

Not having a POSIX API does not preclude using GCC, it merely precludes using the GNU C library. On embedded systems without POSIX, alternative C libraries are used such as Newlib. Newlib has a system porting layer where I/O and basic heap management are implemented.

这篇关于如何在嵌入式上进行代码覆盖的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！