Code Coverage on RTEMS/LEON system

[Joel Sherrill]

On Thu, Jul 16, 2020 at 8:22 AM Scott Zemerick <scott at zemericks.com> wrote:

> Hello!
>
> We are attempting to perform code coverage for an RTEMS based mission.
> Specifically, we are running the Gaisler RCC toolchain/kernel for a
> LEON/SPARC based system. Initially, we believed we could simply use the
> GCOV/LCOV packages. The first issue we faced was what seems to be
> compatibility issues with library versions or something of that nature. We
> base that on some linker issues that seem related to the __gcov_flush
> function being renamed __gcov_exit (or perhaps vice versa). We played some
> tricks with the libgcov.a archive to rename the function to get past this
> error as a temporary hack. Once we figured out the appropriate build flags
> and verified the __gcov symbols existed in the executable, we were unable
> to collect metrics (the gcda files were never generated). After further
> investigation (inspection, attaching gdb, etc.), it appears the second
> issue was that the implementations of all __gcov related functions are
> empty. The gcc/libgcc/libgcov-interface.c file appears to contain the
> definitions and it seems like during compilation the inhibit_libc macro
> might have been set, which results in those functions being empty.
>

The way gcov normally works is that those methods write files at program
exit.  That won't work generally on embedded hardware.

There are two options in your case. I think one is to use the gcov support
built into tsim. I think it gathers the information in the simulator and
can write the files.

The other is to use the coverage bitmap dumps and run covoar on it.
covoar is in rtems-tools.  That's the program we have used to do RTEMS
coverage with traces from sis, tsim and qemu (Couverture variant).

>
> This leads to the following questions:
> Is GCOV supported in RTEMS or is this a limitation of the specific
> architecture? If supported, do you have any guidance? Perhaps we need to
> move away from the Gaisler package and build the toolchain using
> appropriate flags using the RTEMS source builder.
> If not supported, are there any recommendations? We see the covoar tool
> mentioned on the website but have no experience with it. Would that allow
> executing software and producing artifacts similar to GCOV that can then be
> read/analyzed? Do you have any references or examples of how to use?
>

covoar assumes something generates a trace or coverage bit map. The source
has support for a handful of  formats. It reads the various coverage maps
for exe's and logically combines them. It logically takes a set of symbols
and exe's as input and produces reports.

Support for it is integrated into rtems-test.

In fairness, I should warn you that we see cases where the size of the same
method is reported as different sizes in two different executables. In the
past, this has been because it has different amounts of nops appended to
align the following method. The code was switched from using nm and
addr2line to an elf/dwarf library and this previously addressed issue is
back again. Given a test case, it is easy to fix. But right now, I don't
think we have a test case to work against.

Please ask questions. The student who did the last round of work
integrating covoar into rtems-tester is very helpful.

--joel

>
> Thanks!
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20200718/81b76990/attachment.html>