Gcov support in Covoar

[Joel Sherrill]

On Wed, Jul 4, 2018, 3:06 AM Chris Johns <chrisj at rtems.org> wrote:

>
>
> On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote:
> > On 4 July 2018 at 13:09, Chris Johns <chrisj at rtems.org
> > <mailto:chrisj at rtems.org>> wrote:
> >
> >     On 4/7/18 5:38 pm, Chris Johns wrote:
> >     > On 4/7/18 4:52 pm, Vijay Kumar Banerjee wrote:
> >     >>
> >     >> I'm starting this thread for discussions on the gcov support
> >     >> in covoar.
> >     >>
> >     >> Current status is that the code in it (like in GcovData.cc)
> remained untouched
> >     >> for a long time and it had not been updated after the source
> tree reorganization
> >     >> which is why it runs into segmentation
> >     >> fault while trying to find the source files.
> >     >>
> >     >> Joel was suggesting to copy the file gcov-io.h from the gcc
> >     >> source after a license discussion here.
> >     >
> >     > What license the file's license?
> >
> >     Sorry .. What is the file's license?
> >
> > GPL version 3
>
> This license is not suitable.
>

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.

I don't see anyway to interpret gcno or write gcda data otherwise.

How does llvm address this? Don't that have the same issue?

Ultimately we have two file formats that we have to deal with that GCC for
sure defines and llvm might also.


> >     > We are aiming to have all code under the RTEMS Tools under a BSD
> or compatible
> >     > license. Are there other options that have a more suitable license?
>

Llvm would be the only option but this has the rules time exception like
the RTEMS historical license so it non-viral.

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.

>     >
> >     > Also, could you please explain how gcov fits into the coverage
> testing?
> >     >
> >
> > gcov is a test coverage program by gcc that generates
> statement-by-statement
> > profiling.
> > (https://gcc.gnu.org/onlinedocs/gcc/Gcov-Intro.html)
>
> Yes.
>
> > once we're able to generate gcov reports we can run graphical tools like
> lcov or
> > gcovr to generate html and xml reports with detailed coverage data.
> > an example of lcov report:
> >
> http://ltp.sourceforge.net/coverage/lcov/output/example/methods/iterate.c.gcov.html
> >
>
> Do you want to export gcov files from the other trace formats we handle?
>

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.



> How does this fit into the RTEMS Tester tool?
>

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.

It is the path to another report format.

>
> Chris
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180704/48b50f47/attachment-0002.html>