<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 8 July 2018 at 01:08, Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span><div><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 7, 2018, 2:33 PM Chris Johns <<a href="mailto:chris@contemporary.net.au" target="_blank">chris@contemporary.net.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 5 Jul 2018, at 3:07 am, Joel Sherrill <<a href="mailto:joel@rtems.org" rel="noreferrer" target="_blank">joel@rtems.org</a><br>
<mailto:<a href="mailto:joel@rtems.org" rel="noreferrer" target="_blank">joel@rtems.org</a>>> wrote:<br>
> On Wed, Jul 4, 2018, 3:06 AM Chris Johns <<a href="mailto:chrisj@rtems.org" rel="noreferrer" target="_blank">chrisj@rtems.org</a><br>
> <mailto:<a href="mailto:chrisj@rtems.org" rel="noreferrer" target="_blank">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></blockquote></div></div><div dir="auto"><br></div></span><div dir="auto">This is just a description of how it works. Not a particular change. </div><span><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><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 user. Is<br>
this an option to 'rtems-test'?<br>
<br>
The aim of the 'rtems-test' command is to provide a documented user interface.<br>
Providing direct access to covoar adds more documentation and 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 and that<br>
is an interface we will not document and change. <br></blockquote></div></div><div dir="auto"><br></div></span><div dir="auto">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.</div><div dir="auto"><br></div></div></blockquote><div>once covoar can generate the gcov reports, we can add it as an option to rtems test.</div><div>we can generate a file with the list of the notes/trace files from the script which will work as an</div><div>input to covoar, the user won't have to do anything manually.  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">The gcov reports have their own positive attributes. Particularly when you combine them with something like gcovr which can generate xml.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Chris<br>
</blockquote></div></div></div>
</blockquote></div><br></div></div>