Hi everybody,<br><br>Does anybody knows how RTEMS is handling (if it does) test coverage analysis in the embedded platforms? either for applications or RTEMS itself?<br><br>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.<br>
<br>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. <br>
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 information).<br>This needs to be done by the libgcov library, which needs to be linked with the already hooked software.<br>
<br>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 embedded systems)<br><br>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.<br><br>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.<br>
<br>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....<br><br>I am gonna do it anyway...so if RTEMS want benefit from the tool...just let me know.<br>
<br>Cheers,<br><br>Aitor<br><br><br><br><br>