How to make code coverage inline

Question

I am writing a project for an embedded system other than POSIX, so I cannot use the gcc --coverage option (I am not reading or writing). What else can I do to create gcov as output. I have an output function.

Answer 1

This is easiest done with a processor with built-in trace, the design of the board that provides the trace port, and a suitable hardware debugger and associated software. For example, many Cortex-M-based devices include an integrated ARM microprocessor chip (ETM), and this is supported by the Keil uVision IDE and ULINK-Pro debugger to provide code coverage and command / source level tracking, as well as real-time profiling. Hardware tracing has the advantage that it is not intrusive - the code works in real time.

If you do not have hardware support, you may have to resort to a simulation. Many tool chains include an instruction level simulator that will perform tracing, code coverage, and profiling, but you may have to create debug scripts or code stubs to simulate hardware to force all paths to be executed.

A third alternative is to create code on a desktop platform with stubs to replace target hardware dependencies and perform testing and code coverage. You must believe that the target C compiler and the test system compiler translate the source with identical semantics. The advantage here is that affordable debugging tools often outperform those available for embedded systems. You can also test most of your code before any hardware is available, and in most cases run the code much faster, possibly allowing for more extensive testing.

Having no POSIX API does not preclude the use of GCC, it simply eliminates the use of the GNU C library. On embedded systems without POSIX, alternative C libraries such as Newlib are used. Newlib has a system transfer layer in which I / O and database management operations are implemented.

Answer 2

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

As embedded systems bring their own, special, and widely changing requirements, the “best” solution for code coverage also varies greatly.

• If you have trace-based devices such as ARM chips with ETM or NEXUS elements, you can perform tool-free coverage using debuggers.
• Otherwise, you most likely came across a hardware-oriented solution:
  • For solutions with limited memory, a good solution is to write devices to the I / O port
  • Alternatively, you can write devices to the RAM buffer and use a wide variety of tools to extract this from the target.

Of course, many different code coverage options are available: function, operator, solution / branch, MC / DC

Answer 3

Our family of C / C ++ testing tools uses the source code to create a program that you compile with the built-in compiler, which will collect the test to capture the data in a "small" data structure added to the program. It works with various dialects, including ANSI, GCC, Microsoft, and GreenHills.

You need to export this data structure from the built-in execution context to a file on the PC; this is often easy to do with a spare serial or parallel port and a small amount of custom code specific to your port. The tools will provide insights and brief summaries of the test results with these resulting files.

Thus, you can use these tools to collect test coverage data from an embedded system in most practical cases.