<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hello,</div><div class="gmail_quote"><br></div><div class="gmail_quote">As suggested by Joel, I have tried to figure out the structure of</div><div class="gmail_quote">the gcno files and written a gcno dumper.</div><div class="gmail_quote">This is not complete yet, I'm still working on it and I'll keep adding</div><div class="gmail_quote">to it as I "decode" the gcno files. </div><div class="gmail_quote"><br></div><div class="gmail_quote">I'm attaching the c++ code, the gcno file I'm testing on and the txt</div><div class="gmail_quote">file generated from it.</div><div class="gmail_quote"><br></div><div class="gmail_quote">please have a look. Is it moving in the right direction ?</div><div class="gmail_quote"><br></div><div class="gmail_quote">On 12 July 2018 at 03:56, Vijay Kumar Banerjee <span dir="ltr"><<a href="mailto:vijaykumar9597@gmail.com" target="_blank">vijaykumar9597@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">https://devel.rtems.org/<wbr>ticket/3468</a><span class="HOEnZb"><font color="#888888"><br></font></span></div></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_2237470473909627019gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">-- vijay</div></div></div></div></div></font></span><div><div class="h5">
<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" target="_blank">joel@rtems.org</a> <mailto:<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>>><br>
<span>> wrote:<br>
> <br>
> On Sat, Jul 7, 2018, 2:33 PM Chris Johns <<a href="mailto:chris@contemporary.net.au" target="_blank">chris@contemporary.net.au</a><br>
</span><span>> <mailto:<a href="mailto:chris@contemporary.net.au" target="_blank">chris@contemporary.ne<wbr>t.au</a>>> wrote:<br>
> <br>
> On 5 Jul 2018, at 3:07 am, Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a><br>
> <mailto:<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>><br>
</span><span>> <mailto:<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a> <mailto:<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>>>> wrote:<br>
> > On Wed, Jul 4, 2018, 3:06 AM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>><br>
</span><div><div class="m_2237470473909627019h5">> > <mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a> <mailto:<a href="mailto:chrisj@rtems.org" 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>
> <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="m_2237470473909627019HOEnZb"><font color="#888888"><br>
Chris<br>
</font></span></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div>