8

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.

Guy
  • 501
  • 2
  • 4
  • 13
  • 1
    Code coverage is much less commonly done on embedded systems. But a good answer for you question requires a lot more details about your system. What CPU? What OS? What compiler toolchain? – TJD Dec 19 '11 at 18:01
  • 1
    do you just need a write function or a read and write function? If just write (open, close, write) you can create your own and perhaps have the write output go to a serial port to be stored/logged elsewhere. – old_timer Dec 19 '11 at 18:36
  • Is it possible to compile and run tests on a system where you can use the coverage option? – Shaun Wilde Dec 19 '11 at 21:30

4 Answers4

9

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.

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.

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.

Clifford
  • 88,407
  • 13
  • 85
  • 165
2

Disclaimer: The company (Rapita Systems) I work for provides a code coverage solution aimed at embedded applications.

Because embedded systems bring their own, special and widely varying requirements, the "best" solution for code coverage also varies widely.

  • Where you have trace-based devices, like ARM chips with ETM or NEXUS-enabled parts, you can perform coverage without instrumentation via debuggers.
  • Otherwise, you are most likely faced with an instrumentation-based solution:
    • For RAM-limited solutions, a good solution is to write instrumentation to an I/O port
    • Alternatively, you can record instrumentation to a RAM buffer, and use a wide variety of means to extract this from the target.

Of course lots of different flavours of code coverage are also available: function, statement, decision/branch, MC/DC

Andrew Coombes
  • 21
  • 1
0

If your embedded target is supported by GCC-based cross-toolchains, you may find my blog post useful.

The main idea is that you compile your code with the appropriate gcov options, and then create the coverage information in memory (what in the end is stored in .gcda files). You can then place appropriate breakpoints with your GDB, and dump this information over your debug link (serial, JTAG, whatever).

Have a look at my blog post - I describe things in great detail.

ttsiodras
  • 10,602
  • 6
  • 55
  • 71
0

Our family of C/C++ test coverage tools instrument the source code, producing a program you compile with you embedded compiler, that will collect test coverage data into a "small" data structure added to the program. This works with various dialects including ANSI, GCC, Microsoft and GreenHills.

You have to export that data structure from the embedded execution context to a file on a PC; this is often easy to do with a spare serial or parallel port and a small bit of custom code specific to your port. The tools will provide test coverage views and summaries with that resulting files.

So, you can use these tools to collect test coverage data from your embedded system, in most practical circumstances.

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341