Gcov support in Covoar
Vijay Kumar Banerjee
vijaykumar9597 at gmail.com
Thu Jul 19 03:31:40 UTC 2018
Hello,
I have made the changes and also got the confusion with
structure of gcno, cleared to some extent after some
careful reading and experiments.
I'm attaching the txt file generated. So far it is complete up to
function record, next is the basic block records. I will start with
the block records after finalizing the wrapup of the non-gcov
coverage reports to make sure that everything works properly there.
-- vijay
On 18 July 2018 at 17:17, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
wrote:
> 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/20180719/4ea18147/attachment-0002.html>
-------------- next part --------------
MAGIC : 0x67636e6f
VERSION : 0x41373352
TIMESTAMP: 0x5fc87a56
READING NOTE RECORDS
FUNCTION TAG : 1
FUNCTION LENGTH : 29
FUNCTION IDENT : 0x47f3d62f
LINE_NO CHECKSUM : 0x9417fabe
CFG CHECKSUM : 0x4f7a5af2
FUNCTION NAME LENGTH : 5
FUNCTION NAME : _Timespec_Less_than
SOURCE NAME LENGTH : 18
SOURCE NAME : ../../../../../../rtems/c/src/../../cpukit/score/src/timespeclessthan.c
LINE NUMBER : 26
More information about the devel
mailing list