[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Wed, 2 Apr 2008 23:51:21 +0200
- From: aitor.viana.sanchez at esa.int (Aitor Viana)
- Subject: GCOV
Does anybody knows how RTEMS is handling (if it does) test coverage analysis
in the embedded platforms? either for applications or RTEMS itself?
I am making that question because I started not to far ago to write
something allowing embedded SW coverage analysis by means of gcov. I already
get something running for ERC32 and LEON2 allowing the coverage analysis for
one source file...and I am about continue (in the spare time) the
development to address the full implementation.
When you want to perform gcov analysis, you compile the source files with
the "-fprofile-arcs" and "-ftest-coverage" flags. GCC then will instrument
the code adding the line counting and hooks to the "libgcov" library, which
is the one retrieving the coverage information after execution.
The calls being hooked by gcc are empty, so only doing this, the SW would
actually would do nothing when executing (we would not retrieve the coverage
This needs to be done by the libgcov library, which needs to be linked with
the already hooked software.
This library is the one I am implementing for embedded systems, as the
normal one just dumps the coverage information in files (not good for
Basically what I am planning is to send the .gcda (is the file which will
hold the coverage analysis data) through for instance a serial line, though
I think will be to slow interface. That's why I am also planning to support
any other high speed comm. links, like Ethernet, spacewire, etc. An also let
the gcov library software being as scalable and portable as possible.
The idea is to have a client in the embedded target sending the information
to the host where a server is being executed and is putting together
everything again in files. (.gcda files). Those files will be then analyzed
by gcov after execution.
I think, this could be a tool that might be integrated within RTEMS
distribution for application testing purposes. Even more, it may also be
tuned to support RTEMS overage analysis....
I am gonna do it anyway...so if RTEMS want benefit from the tool...just let
-------------- next part --------------
An HTML attachment was scrubbed...
- From: chrisj at rtems.org (Chris Johns)