Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

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 
wrote:

> On 18 July 2018 at 02:30, Joel Sherrill  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 <
>> vijaykumar9...@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 >> > 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  wrote:

> On 8/7/18 7:51 am, Vijay Kumar Banerjee wrote:
> > On 8 July 2018 at 01:08, Joel Sherrill  j...@rtems.org>>
> > wrote:
> >
> > On Sat, Jul 7, 2018, 2:33 PM Chris Johns <
> ch...@contemporary.net.au
> > > wrote:
> >
> > On 5 Jul 2018, at 3:07 am, Joel Sherrill  > 
> > >> wrote:
> > > On Wed, Jul 4, 2018, 3:06 AM Chris Johns  
> > > >>
> 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 

Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

On 18 July 2018 at 02:30, Joel Sherrill  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 <
> vijaykumar9...@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 
>> 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  wrote:
>>>
 On 8/7/18 7:51 am, Vijay Kumar Banerjee wrote:
 > On 8 July 2018 at 01:08, Joel Sherrill >>> j...@rtems.org>>
 > wrote:
 >
 > On Sat, Jul 7, 2018, 2:33 PM Chris Johns <
 ch...@contemporary.net.au
 > > wrote:
 >
 > On 5 Jul 2018, at 3:07 am, Joel Sherrill >>> > 
 > >> wrote:
 > > On Wed, Jul 4, 2018, 3:06 AM Chris Johns >>> 
 > > >> 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.
 >
 >

Re: 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 <
vijaykumar9...@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 
> 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  wrote:
>>
>>> On 8/7/18 7:51 am, Vijay Kumar Banerjee wrote:
>>> > On 8 July 2018 at 01:08, Joel Sherrill >> j...@rtems.org>>
>>> > wrote:
>>> >
>>> > On Sat, Jul 7, 2018, 2:33 PM Chris Johns <
>>> ch...@contemporary.net.au
>>> > > wrote:
>>> >
>>> > On 5 Jul 2018, at 3:07 am, Joel Sherrill >> > 
>>> > >> wrote:
>>> > > On Wed, Jul 4, 2018, 3:06 AM Chris Johns >> 
>>> > > >> 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.
>>>
>>> 

Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

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  wrote:

> On 8/7/18 7:51 am, Vijay Kumar Banerjee wrote:
> > On 8 July 2018 at 01:08, Joel Sherrill  j...@rtems.org>>
> > wrote:
> >
> > On Sat, Jul 7, 2018, 2:33 PM Chris Johns  > > wrote:
> >
> > On 5 Jul 2018, at 3:07 am, Joel Sherrill  > 
> > >> wrote:
> > > On Wed, Jul 4, 2018, 3:06 AM Chris Johns  
> > > >> 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

On 8 July 2018 at 01:08, Joel Sherrill  wrote:

>
>
> On Sat, Jul 7, 2018, 2:33 PM Chris Johns 
> wrote:
>
>> On 5 Jul 2018, at 3:07 am, Joel Sherrill > > wrote:
>> > On Wed, Jul 4, 2018, 3:06 AM Chris Johns > > > 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.

> The gcov reports have their own positive attributes. Particularly when you
> combine them with something like gcovr which can generate xml.
>
>>
>> Chris
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcov support in Covoar

[Joel Sherrill]

On Sat, Jul 7, 2018, 2:33 PM Chris Johns  wrote:

> On 5 Jul 2018, at 3:07 am, Joel Sherrill  > wrote:
> > On Wed, Jul 4, 2018, 3:06 AM Chris Johns  > > 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.

The gcov reports have their own positive attributes. Particularly when you
combine them with something like gcovr which can generate xml.

>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

On 6 July 2018 at 23:50, Joel Sherrill  wrote:

>
>
> On Thu, Jul 5, 2018, 3:31 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> I think that the whole gcov support needs to be reworked.
>>
>
> I am unsure the scope of what you have in mind.
>
>
>> I was looking into how llvm outputs their gcov data in gcda file
>> format here
>> https://github.com/llvm-mirror/compiler-rt/blob/master/lib/
>> profile/GCDAProfiling
>>
>> 
>>
>
> For normal native coverage runs, the program itself is instrumented and
> writes "records" into a buffer as it runs. On program exit, the records are
> written to the gcda file.
>
> Running cross, we don't want the object instrumented and nothing
> can be written at program exit.
>
> Understood.

>
>> 
>>
>> I need some help in understanding the workflow of how covoar
>> gets the trace input and how that is dumped into a gcda file.
>>
>
> This is a purely logical description.
>
> Based on the analysis before the point the gcov generation is reached,
> you know what lines of code have been executed. This is 0/1 information
> not count which might be useful for profiling in the future.
>
> Each line is part of a basic block or arc. I am assuming that the gcno
> file gives us information on the basic blocks/arcs. covoar uses this
> information to figure out which basic block each covered instruction
> range represents. Then it writes the corresponding gcda record for
> that executed range.
>
> That looks like all the "generate gcov data" block of code is doing
> in covoar.cc.
>
> Okay, it's getting clearer gradually each day. :)

> NOTE: Every gcno file has to be processed. I assume that this code
> has a loop buried under it somewhere.
>
 Yes there's a loop inside.
My next objective it to figure out how to loop over the source file names
corresponding the the gcno file names.
I think if that works out, it will significantly get us started.

>
>
>>
>> What files are involved in the process (other than GcovData.cc and
>> GcovFunctionData.cc ) and what are their roles ?
>>
>
> That should be it from what I can tell.  You already have the
> entire set of data on what was executed. This is just a translation
> pass to saw "line x of file Y was executed". That corresponds to
> some piece of data in the gcno file and that is used to write the
> data into the gcda file which says that range was executed.
>
> We may need Martin to help us with the details of mapping source file/line
> to gcno data to gcda data but that's it.
>
Martin's help is really needed, as I can see that we're manking a lot
of assumptions about the gcno files and it's structure.
There is a possibility that the structure of the gcno files have changed
a bit, since the time this code was written, only Martin can say if we're
in the right direction with this.

The code in GcovData has some assumptions, which are mentioned in
the comments. I don't have any idea about them, Martin might need
to go through the code to help us solve them one by one.

>
>> I feel that this is very difficult to be able to do the whole work within
>> the GSoC period and the work will go on post GSoC as well.
>> So we need to set milestones specific to GSoC and then continue
>> from there post GSoC.
>>
>
> :) It's understandable. Let's just keep pushing and continue as needed.
>
> This should just be a matter of threading the pieces of information
> together.
>
> Thanks for the explanation.
We'll hopefully get it working soon. :)

> --joel
>
>
>>
>> On 5 July 2018 at 00:50, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Wed, Jul 4, 2018, 1:46 PM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 4 July 2018 at 22:37, Joel Sherrill  wrote:

>
>
> On Wed, Jul 4, 2018, 3:06 AM Chris Johns  wrote:
>
>>
>>
>> On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote:
>> > On 4 July 2018 at 13:09, Chris Johns > > > 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 

Re: Gcov support in Covoar

[Joel Sherrill]

On Thu, Jul 5, 2018, 3:31 PM Vijay Kumar Banerjee 
wrote:

> I think that the whole gcov support needs to be reworked.
>

I am unsure the scope of what you have in mind.


> I was looking into how llvm outputs their gcov data in gcda file
> format here
> https://github.com/llvm-mirror/compiler-rt/blob/master/lib/profile/
> GCDAProfiling
>
> 
>

For normal native coverage runs, the program itself is instrumented and
writes "records" into a buffer as it runs. On program exit, the records are
written to the gcda file.

Running cross, we don't want the object instrumented and nothing
can be written at program exit.


>
> I need some help in understanding the workflow of how covoar
> gets the trace input and how that is dumped into a gcda file.
>

This is a purely logical description.

Based on the analysis before the point the gcov generation is reached,
you know what lines of code have been executed. This is 0/1 information
not count which might be useful for profiling in the future.

Each line is part of a basic block or arc. I am assuming that the gcno
file gives us information on the basic blocks/arcs. covoar uses this
information to figure out which basic block each covered instruction
range represents. Then it writes the corresponding gcda record for
that executed range.

That looks like all the "generate gcov data" block of code is doing
in covoar.cc.

NOTE: Every gcno file has to be processed. I assume that this code
has a loop buried under it somewhere.


>
> What files are involved in the process (other than GcovData.cc and
> GcovFunctionData.cc ) and what are their roles ?
>

That should be it from what I can tell.  You already have the
entire set of data on what was executed. This is just a translation
pass to saw "line x of file Y was executed". That corresponds to
some piece of data in the gcno file and that is used to write the
data into the gcda file which says that range was executed.

We may need Martin to help us with the details of mapping source file/line
to gcno data to gcda data but that's it.

>
> I feel that this is very difficult to be able to do the whole work within
> the GSoC period and the work will go on post GSoC as well.
> So we need to set milestones specific to GSoC and then continue
> from there post GSoC.
>

:) It's understandable. Let's just keep pushing and continue as needed.

This should just be a matter of threading the pieces of information
together.

--joel


>
> On 5 July 2018 at 00:50, Joel Sherrill  wrote:
>
>>
>>
>> On Wed, Jul 4, 2018, 1:46 PM Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 4 July 2018 at 22:37, Joel Sherrill  wrote:
>>>


 On Wed, Jul 4, 2018, 3:06 AM Chris Johns  wrote:

>
>
> On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote:
> > On 4 July 2018 at 13:09, Chris Johns  > > 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?

 llvm defines it in GCOV.h file in llvm/ProfileData/ under the license
>>> it's mentioned there that it's distributed under University of Illinois
>>> Open Source License
>>> https://github.com/llvm-mirror/llvm/blob/master/
>>> include/llvm/ProfileData/GCOV.h
>>> 
>>>
>>
>> That would be the preferred way to get this header. Is it technically
>> acceptable?
>>
>> Chris.. license acceptable to you?
>>
>>>
>>> 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
> 

Re: Gcov support in Covoar

[Joel Sherrill]

On Wed, Jul 4, 2018, 1:46 PM Vijay Kumar Banerjee 
wrote:

> On 4 July 2018 at 22:37, Joel Sherrill  wrote:
>
>>
>>
>> On Wed, Jul 4, 2018, 3:06 AM Chris Johns  wrote:
>>
>>>
>>>
>>> On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote:
>>> > On 4 July 2018 at 13:09, Chris Johns >> > > 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?
>>
>> llvm defines it in GCOV.h file in llvm/ProfileData/ under the license
> it's mentioned there that it's distributed under University of Illinois
> Open Source License
>
> https://github.com/llvm-mirror/llvm/blob/master/include/llvm/ProfileData/GCOV.h
> 
>

That would be the preferred way to get this header. Is it technically
acceptable?

Chris.. license acceptable to you?

>
> 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@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcov support in Covoar

[Joel Sherrill]

On Wed, Jul 4, 2018, 3:06 AM Chris Johns  wrote:

>
>
> On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote:
> > On 4 July 2018 at 13:09, Chris Johns  > > 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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

On 4 July 2018 at 13:36, Chris Johns  wrote:

>
>
> On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote:
> > On 4 July 2018 at 13:09, Chris Johns  > > 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.
>
> > > 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?
> > >
> > > 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?
>
> How does this fit into the RTEMS Tester tool?
>
>
this is a basic outline of the plan :

   - gcc generates the .gcno notes file at the compile time
   - covoar reads these gcno files and the trace files from qemu and
   produces the gcda files that can be processed by gcov.
   - gcov processes gcno and gcda files to produce coverage reports.



> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcov support in Covoar

[Chris Johns]

On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote:
> On 4 July 2018 at 13:09, Chris Johns  > 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.

> > 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?
> > 
> > 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?

How does this fit into the RTEMS Tester tool?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

On 4 July 2018 at 13:09, Chris Johns  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

> >
> > 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?
> >
> > 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)

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

> > Chris
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcov support in Covoar

[Chris Johns]

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?

> 
> 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?
> 
> Also, could you please explain how gcov fits into the coverage testing?
> 
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcov support in Covoar

[Chris Johns]

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?

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?

Also, could you please explain how gcov fits into the coverage testing?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: gcov support in Covoar

[Vijay Kumar Banerjee]

On 14 May 2018 at 23:37, Joel Sherrill  wrote:

>
>
> On Mon, May 14, 2018 at 12:43 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 14 May 2018 at 21:21, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Mon, May 14, 2018 at 10:19 AM, Vijay Kumar Banerjee <
>>> vijaykumar9...@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. :)
>
Hopefully.

>
>
>>
>>
>>>
>>>

 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.
>
Yeah that will be the approach.

>
>
>>
>>> 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
>
Thanks for the links

>
>
> 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.
>
> This needs to be looked into properly to undertsand how the versions
impact the report generation.

> Randomly found this tool which looks like another option for more
> reports/analysis once gcov
> files are available:
>
> https://gcovr.com/guide.html
>
>
it says XML reports!
Looks like we have some cool options to try out once we get the initial
steps done.

>
 Thank you,

>>>
> R
>
>>
 Vijay



>>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: gcov support in Covoar

[Joel Sherrill]

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

> On 14 May 2018 at 21:21, Joel Sherrill  wrote:
>
>>
>>
>> On Mon, May 14, 2018 at 10:19 AM, Vijay Kumar Banerjee <
>> vijaykumar9...@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
>>>
>>>
>>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: gcov support in Covoar

[Vijay Kumar Banerjee]

On 14 May 2018 at 21:21, Joel Sherrill  wrote:

>
>
> On Mon, May 14, 2018 at 10:19 AM, Vijay Kumar Banerjee <
> vijaykumar9...@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 .

>
>
>>
>> 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

>
> 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 .
>>
>> Thank you,
>>
>> Vijay
>>
>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: gcov support in Covoar

[Joel Sherrill]

On Mon, May 14, 2018 at 10:19 AM, Vijay Kumar Banerjee <
vijaykumar9...@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.


>
> 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.

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 .
>
> Thank you,
>
> Vijay
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel