gcov support in Covoar

[Joel Sherrill]

On Mon, May 14, 2018 at 12:43 PM, Vijay Kumar Banerjee <
vijaykumar9597 at gmail.com> wrote:

> On 14 May 2018 at 21:21, Joel Sherrill <joel at rtems.org> wrote:
>
>>
>>
>> On Mon, May 14, 2018 at 10:19 AM, Vijay Kumar Banerjee <
>> vijaykumar9597 at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> The coverage report is showing some data now (txt only). There is still
>>> some work needed to be done for it to get merged with the main repo. As it
>>> depends on the ongoing work on the covoar.cc and coverage.py, meanwhile I
>>> want to get started with the gcov support in covoar as I already have some
>>> coverage data in txt format to compare with .
>>>
>>> I would like to know the following points to get started:
>>>
>>>     1. What is the current state of the gcov support in covoar. I can
>>> see work on GcovData and GcovFunction data in covoar, what's the current
>>> status of it ?
>>>
>>
>> Technically unknown, potentially bit rotted.
>>
> Seems like it will take some time before it starts making sense .
>

Maybe. Since you can produce coverage reports now, I am betting it
will likely work quickly. :)


>
>
>>
>>
>>>
>>>     2. Did it use to run at some point? seeing it in action will be very
>>> helpful.
>>>
>>
>> It used to produce .gcov files that could be processed by gcov and
>> produce reports.
>>
> Then our very first objective is to get the .gcov file output only then
> can we proceed with the  discripancies
>

Yes.

Use the same test executables and symbols of interest.

I suspect you have been looking at a report for the same test exe and the
same methods.
Just check that the report from gcov matches. If it doesn't, then we have a
small test case.


>
>> Once you started to compare the reports to the native reports from
>> covoar, you would sometimes see places that covoar thought some code was
>> executed that did not show up in the gcov generated report. When I
>> investigated, I got far enough to know we had executed the code in question.
>>
>>
>>>
>>>     3. What are the listed blockers rn ? Other than the reliability of
>>> the report .
>>>
>>
>> That's it. Get it working and then let's work on automation, use of lcov,
>> etc. Along the way, I am sure we will spot the difference in reporting.
>> Then that will have to be fixed.
>>
>>
>>>     4. are there any tickets related to gcov?
>>>
>>
>> Not from RTEMS' perspective.
>>
>> One challenge we had previously is that the .gcov file format was only
>> documented in the header file. That was why I asked for someone from the
>> gcc community to help us once we spot difference. Hopefully they can help
>> us figure out what is wrong with the file covoar is producing.
>>
>
>>> Please add any suggestions or references that might help me get started
>>> properly .
>>>
>>
https://gcc.gnu.org/onlinedocs/gcc/Gcov-Data-Files.html is an overview from
a gcc user's perspective.

The details are in the gcc source code. This should be the current version
of the gcov file:

https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov-io.h

I don't remember a comment in the version in covoar specifying that the
format could change
with GCC versions. Maybe that's the gcno data and not the coverage data.

Randomly found this tool which looks like another option for more
reports/analysis once gcov
files are available:

https://gcovr.com/guide.html


>
>>> Thank you,
>>>
>>
R

>
>>> Vijay
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180514/ab30ae3d/attachment-0002.html>