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