Gcov support in Covoar

[Joel Sherrill]

This definitely looks like the right direction. If we don't understand
the file formats, we will never be able to process and correlate them.

Please put 0x in front of hex numbers. It does help.

Can you explain the fields in gcno_dump.txt? The Version field
looks like hex for R37A which doesn't make sense to me. Reading the
header in gcov-io.h, I wonder how it matches this pattern?

================================
Although the ident and version are formally 32 bit numbers, they
   are derived from 4 character ASCII strings.  The version number
   consists of a two character major version number
   (first digit starts from 'A' letter to not to clash with the older
   numbering scheme), the single character minor version number,
   and a single character indicating the status of the release.
   That will be 'e' experimental, 'p' prerelease and 'r' for release.
   Because, by good fortune, these are in alphabetical order, string
   collating can be used to compare version strings.  Be aware that
   the 'e' designation will (naturally) be unstable and might be
   incompatible with itself.  For gcc 17.0 experimental, it would be
   'B70e' (0x42373065).  As we currently do not release more than 5 minor
   releases, the single character should be always fine.  Major number
   is currently changed roughly every year, which gives us space
   for next 250 years (maximum allowed number would be 259.9).
================================


The timestamp field also doesn't make sense to me. Assuming that
is a hex number, it has a LOT of digits and https://www.epochconverter.com/
tells me that it is sometime in 2741

Maybe you have the endianness of some of the fields wrong.

But this is what it takes to understand it. :)

--joel


On Sat, Jul 14, 2018 at 4:29 PM, Vijay Kumar Banerjee <
vijaykumar9597 at gmail.com> wrote:

> Hello,
>
> As suggested by Joel, I have tried to figure out the structure of
> the gcno files and written a gcno dumper.
> This is not complete yet, I'm still working on it and I'll keep adding
> to it as I "decode" the gcno files.
>
> I'm attaching the c++ code, the gcno file I'm testing on and the txt
> file generated from it.
>
> please have a look. Is it moving in the right direction ?
>
> On 12 July 2018 at 03:56, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
> wrote:
>
>> I have filed a ticket for gcov, as suggested by Joel.
>>
>> https://devel.rtems.org/ticket/3468
>>
>> -- vijay
>>
>> On 8 July 2018 at 01:43, Chris Johns <chrisj at rtems.org> wrote:
>>
>>> On 8/7/18 7:51 am, Vijay Kumar Banerjee wrote:
>>> > On 8 July 2018 at 01:08, Joel Sherrill <joel at rtems.org <mailto:
>>> joel at rtems.org>>
>>> > wrote:
>>> >
>>> >     On Sat, Jul 7, 2018, 2:33 PM Chris Johns <
>>> chris at contemporary.net.au
>>> >     <mailto:chris at contemporary.net.au>> wrote:
>>> >
>>> >         On 5 Jul 2018, at 3:07 am, Joel Sherrill <joel at rtems.org
>>> >         <mailto:joel at rtems.org>
>>> >         <mailto:joel at rtems.org <mailto:joel at rtems.org>>> wrote:
>>> >         > On Wed, Jul 4, 2018, 3:06 AM Chris Johns <chrisj at rtems.org
>>> <mailto:chrisj at rtems.org>
>>> >         > <mailto:chrisj at rtems.org <mailto:chrisj at rtems.org>>> wrote:
>>> >         >
>>> >         >     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.
>>> >
>>> >
>>> >     This is just a description of how it works. Not a particular
>>> change.
>>> >
>>> >         >
>>> >         > It is the path to another report format.
>>> >
>>> >         I am not sure I understand how we make this work and how we
>>> support the
>>> >         user. Is
>>> >         this an option to 'rtems-test'?
>>> >
>>> >         The aim of the 'rtems-test' command is to provide a documented
>>> user
>>> >         interface.
>>> >         Providing direct access to covoar adds more documentation and
>>> >         complication to
>>> >         the test tool. For example how does the user wanting gcov
>>> output get to the
>>> >         trace files? The user would need to step into how we implement
>>> coverage
>>> >         and that
>>> >         is an interface we will not document and change.
>>> >
>>> >
>>> >     I wouldn't want a user to invoke covoar directly. It is just a
>>> coverage
>>> >     reporting variant at this point. I doubt it will ever be the
>>> default report
>>> >     format because we have details in the native reports that I don't
>>> think you
>>> >     can get ever with gcov. I think the native format is closer to
>>> what you
>>> >     would use on an analysis for the highest level of coverage.
>>> >
>>> > once covoar can generate the gcov reports, we can add it as an option
>>> to rtems test.
>>> > we can generate a file with the list of the notes/trace files from the
>>> script
>>> > which will work as an
>>> > input to covoar, the user won't have to do anything manually.
>>>
>>> Thank you. I now understand.
>>>
>>> Chris
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180717/c6985991/attachment-0001.html>