<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 4, 2018, 3:06 AM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote:<br>
> On 4 July 2018 at 13:09, Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a><br>
> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>>> wrote:<br>
> <br>
>     On 4/7/18 5:38 pm, Chris Johns wrote:<br>
>     > On 4/7/18 4:52 pm, Vijay Kumar Banerjee wrote:<br>
>     >><br>
>     >> I'm starting this thread for discussions on the gcov support <br>
>     >> in covoar.<br>
>     >><br>
>     >> Current status is that the code in it (like in GcovData.cc) remained untouched <br>
>     >> for a long time and it had not been updated after the source tree reorganization<br>
>     >> which is why it runs into segmentation<br>
>     >> fault while trying to find the source files.<br>
>     >><br>
>     >> Joel was suggesting to copy the file gcov-io.h from the gcc<br>
>     >> source after a license discussion here.<br>
>     > <br>
>     > What license the file's license?<br>
> <br>
>     Sorry .. What is the file's license?<br>
> <br>
> GPL version 3 <br>
<br>
This license is not suitable.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It has the runtime exception and is the only file that defines the format of gcno and (need to double-check) gcda file. It does not contaminate anything.</div><div dir="auto"><br></div><div dir="auto">I don't see anyway to interpret gcno or write gcda data otherwise. </div><div dir="auto"><br></div><div dir="auto">How does llvm address this? Don't that have the same issue? </div><div dir="auto"><br></div><div dir="auto">Ultimately we have two file formats that we have to deal with that GCC for sure defines and llvm might also.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>     > We are aiming to have all code under the RTEMS Tools under a BSD or compatible<br>
>     > license. Are there other options that have a more suitable license?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Llvm would be the only option but this has the rules time exception like the RTEMS historical license so it non-viral. </div><div dir="auto"><br></div><div dir="auto">A hack would be to ensure they are installed with the RTEMS GCC by the RSB. But that would be lifting a file out of the GCC source and  one from the build tree that are normally not installed. We could ask about GCC doing that.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>     > <br>
>     > Also, could you please explain how gcov fits into the coverage testing?<br>
>     > <br>
> <br>
> gcov is a test coverage program by gcc that generates statement-by-statement<br>
> profiling.<br>
> (<a href="https://gcc.gnu.org/onlinedocs/gcc/Gcov-Intro.html" rel="noreferrer noreferrer" target="_blank">https://gcc.gnu.org/onlinedocs/gcc/Gcov-Intro.html</a>)<br>
<br>
Yes.<br>
<br>
> once we're able to generate gcov reports we can run graphical tools like lcov or<br>
> gcovr to generate html and xml reports with detailed coverage data.<br>
> an example of lcov report:<br>
> <a href="http://ltp.sourceforge.net/coverage/lcov/output/example/methods/iterate.c.gcov.html" rel="noreferrer noreferrer" target="_blank">http://ltp.sourceforge.net/coverage/lcov/output/example/methods/iterate.c.gcov.html</a><br>
><br>
<br>
Do you want to export gcov files from the other trace formats we handle?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Gcov reads gcda files for execution information. Rather than the executable being instrumented and writing this during execution (libgcov), covoar generates gcda files for unmodified executables using simulator trace information. But you have to read gcno files and write gcda files.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
How does this fit into the RTEMS Tester tool?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">If you want to run gcov or lcov on uninstrumented executables, then covoar has to read gcno and write gcda files. And we have to then run gcov or lcov as normal. </div><div dir="auto"><br></div><div dir="auto">It is the path to another report format.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Chris<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div></div>