Gcov support in Covoar

Vijay Kumar Banerjee vijaykumar9597 at gmail.com
Wed Jul 18 11:47:57 UTC 2018


On 18 July 2018 at 02:30, Joel Sherrill <joel at rtems.org> wrote:

> 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?
>
> it should be A73R, I have corrected it.
I have tried to give some description in the code itself.
I'll write a detailed description of each field once it's complete.
Maybe a blog post will be nice.

> ================================
> 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
>
> There was some issue with it because I was taking signed int.
I fixed it.

> Maybe you have the endianness of some of the fields wrong.
>
> Yes the endianness was wrong.
I have uploaded the code to a github repository so that it can be
visible and progress can be trackable.

https://github.com/thelunatic/gcno_dumper.git

I am working on figuring out how the file is organised, I'll
post the generated txt file soon.

> 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/20180718/98dfdd72/attachment.html>


More information about the devel mailing list