Gcov support in Covoar

[Joel Sherrill]

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

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

>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180707/e996bf76/attachment-0002.html>