<div dir="ltr">This definitely looks like the right direction. If we don't understand<div>the file formats, we will never be able to process and correlate them.</div><div><br></div><div>Please put 0x in front of hex numbers. It does help.</div><div><br>Can you explain the fields in gcno_dump.txt? The Version field</div><div>looks like hex for R37A which doesn't make sense to me. Reading the</div><div>header in gcov-io.h, I wonder how it matches this pattern?<br><br>================================<br><div>Although the ident and version are formally 32 bit numbers, they</div><div> are derived from 4 character ASCII strings. The version number</div><div> consists of a two character major version number</div><div> (first digit starts from 'A' letter to not to clash with the older</div><div> numbering scheme), the single character minor version number,</div><div> and a single character indicating the status of the release.</div><div> That will be 'e' experimental, 'p' prerelease and 'r' for release.</div><div> Because, by good fortune, these are in alphabetical order, string</div><div> collating can be used to compare version strings. Be aware that</div><div> the 'e' designation will (naturally) be unstable and might be</div><div> incompatible with itself. For gcc 17.0 experimental, it would be</div><div> 'B70e' (0x42373065). As we currently do not release more than 5 minor</div><div> releases, the single character should be always fine. Major number</div><div> is currently changed roughly every year, which gives us space</div><div> for next 250 years (maximum allowed number would be 259.9).</div></div><div>
<span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">================================</span>
<br></div><div><br></div><div><br>The timestamp field also doesn't make sense to me. Assuming that</div><div>is a hex number, it has a LOT of digits and <a href="https://www.epochconverter.com/">https://www.epochconverter.com/</a> </div><div>tells me that it is sometime in 2741</div><div><br></div><div>Maybe you have the endianness of some of the fields wrong.</div><div><br></div><div>But this is what it takes to understand it. :)</div><div><br></div><div>--joel</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 14, 2018 at 4:29 PM, 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"><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><div class="h5"><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/ticket<wbr>/3468</a><span class="m_1115166274461983486HOEnZb"><font color="#888888"><br></font></span></div></div><div class="gmail_extra"><span class="m_1115166274461983486HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_1115166274461983486m_2237470473909627019gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">-- vijay</div></div></div></div></div></font></span><div><div class="m_1115166274461983486h5">
<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_1115166274461983486m_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_1115166274461983486m_2237470473909627019HOEnZb"><font color="#888888"><br>
Chris<br>
</font></span></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>