<div dir="ltr">I have filed a ticket for gcov, as suggested by Joel.<div><br></div><div><a href="https://devel.rtems.org/ticket/3468">https://devel.rtems.org/ticket/3468</a><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">-- vijay</div></div></div></div></div>
<br><div class="gmail_quote">On 8 July 2018 at 01:43, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 8/7/18 7:51 am, Vijay Kumar Banerjee wrote:<br>
> On 8 July 2018 at 01:08, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a> <mailto:<a href="mailto:joel@rtems.org">joel@rtems.org</a>>><br>
<span class="">> wrote:<br>
> <br>
>     On Sat, Jul 7, 2018, 2:33 PM Chris Johns <<a href="mailto:chris@contemporary.net.au">chris@contemporary.net.au</a><br>
</span><span class="">>     <mailto:<a href="mailto:chris@contemporary.net.au">chris@contemporary.<wbr>net.au</a>>> wrote:<br>
> <br>
>         On 5 Jul 2018, at 3:07 am, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a><br>
>         <mailto:<a href="mailto:joel@rtems.org">joel@rtems.org</a>><br>
</span><span class="">>         <mailto:<a href="mailto:joel@rtems.org">joel@rtems.org</a> <mailto:<a href="mailto:joel@rtems.org">joel@rtems.org</a>>>> wrote:<br>
>         > On Wed, Jul 4, 2018, 3:06 AM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a> <mailto:<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>><br>
</span><div><div class="h5">>         > <mailto:<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a> <mailto:<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>>>> wrote:<br>
>         ><br>
>         >     How does this fit into the RTEMS Tester tool?<br>
>         ><br>
>         ><br>
>         > If you want to run gcov or lcov on uninstrumented executables, then covoar has<br>
>         > to read gcno and write gcda files. And we have to then run gcov or lcov as<br>
>         > normal.<br>
> <br>
> <br>
>     This is just a description of how it works. Not a particular change. <br>
> <br>
>         ><br>
>         > It is the path to another report format.<br>
> <br>
>         I am not sure I understand how we make this work and how we support the<br>
>         user. Is<br>
>         this an option to 'rtems-test'?<br>
> <br>
>         The aim of the 'rtems-test' command is to provide a documented user<br>
>         interface.<br>
>         Providing direct access to covoar adds more documentation and<br>
>         complication to<br>
>         the test tool. For example how does the user wanting gcov output get to the<br>
>         trace files? The user would need to step into how we implement coverage<br>
>         and that<br>
>         is an interface we will not document and change. <br>
> <br>
> <br>
>     I wouldn't want a user to invoke covoar directly. It is just a coverage<br>
>     reporting variant at this point. I doubt it will ever be the default report<br>
>     format because we have details in the native reports that I don't think you<br>
>     can get ever with gcov. I think the native format is closer to what you<br>
>     would use on an analysis for the highest level of coverage.<br>
> <br>
> once covoar can generate the gcov reports, we can add it as an option to rtems test.<br>
> we can generate a file with the list of the notes/trace files from the script<br>
> which will work as an<br>
> input to covoar, the user won't have to do anything manually.  <br>
<br>
</div></div>Thank you. I now understand.<br>
<span class="HOEnZb"><font color="#888888"><br>
Chris<br>
</font></span></blockquote></div><br></div>