<div dir="ltr"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 5, 2018, 3:31 PM Vijay Kumar Banerjee <<a href="mailto:vijaykumar9597@gmail.com" target="_blank">vijaykumar9597@gmail.com</a>> wrote:<br></div><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">I think that the whole gcov support needs to be reworked.</div></div></div></blockquote><div><br></div><div>I am unsure the scope of what you have in mind.</div><div> </div><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">I was looking into how llvm outputs their gcov data in gcda file</div><div class="gmail_quote">format here</div><div class="gmail_quote"><a href="https://github.com/llvm-mirror/compiler-rt/blob/master/lib/profile/GCDAProfiling.c" rel="noreferrer" target="_blank">https://github.com/llvm-<wbr>mirror/compiler-rt/blob/<wbr>master/lib/profile/<wbr>GCDAProfiling<br></a></div></div></div></blockquote></div></div><div dir="auto"><br></div><div>For normal native coverage runs, the program itself is instrumented and </div><div>writes "records" into a buffer as it runs. On program exit, the records are</div><div>written to the gcda file. </div><div><br></div><div>Running cross, we don't want the object instrumented and nothing</div><div>can be written at program exit. </div><div><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><a href="https://github.com/llvm-mirror/compiler-rt/blob/master/lib/profile/GCDAProfiling.c" rel="noreferrer" target="_blank"></a></div><div class="gmail_quote"><br></div><div class="gmail_quote">I need some help in understanding the workflow of how covoar</div><div class="gmail_quote">gets the trace input and how that is dumped into a gcda file.</div></div></div></blockquote><div><br></div><div>This is a purely logical description.</div><div><br></div><div>Based on the analysis before the point the gcov generation is reached,</div><div>you know what lines of code have been executed. This is 0/1 information</div><div>not count which might be useful for profiling in the future.</div><div><br></div><div>Each line is part of a basic block or arc. I am assuming that the gcno</div><div>file gives us information on the basic blocks/arcs. covoar uses this</div><div>information to figure out which basic block each covered instruction</div><div>range represents. Then it writes the corresponding gcda record for</div><div>that executed range.</div><div><br></div><div>That looks like all the "generate gcov data" block of code is doing</div><div>in covoar.cc.</div><div><br></div><div>NOTE: Every gcno file has to be processed. I assume that this code</div><div>has a loop buried under it somewhere.</div><div> </div><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"><br></div><div class="gmail_quote">What files are involved in the process (other than GcovData.cc and</div><div class="gmail_quote">GcovFunctionData.cc ) and what are their roles ?</div></div></div></blockquote><div><br></div><div>That should be it from what I can tell. You already have the </div><div>entire set of data on what was executed. This is just a translation </div><div>pass to saw "line x of file Y was executed". That corresponds to</div><div>some piece of data in the gcno file and that is used to write the</div><div>data into the gcda file which says that range was executed.</div><div><br></div><div>We may need Martin to help us with the details of mapping source file/line</div><div>to gcno data to gcda data but that's it.</div><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"><br></div><div class="gmail_quote">I feel that this is very difficult to be able to do the whole work within</div><div class="gmail_quote">the GSoC period and the work will go on post GSoC as well.</div><div class="gmail_quote">So we need to set milestones specific to GSoC and then continue </div><div class="gmail_quote">from there post GSoC.</div></div></div></blockquote><div><br></div><div>:) It's understandable. Let's just keep pushing and continue as needed.</div><div><br></div><div>This should just be a matter of threading the pieces of information together.</div><div><br></div><div>--joel</div><div> </div><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"> </div><div class="gmail_quote">On 5 July 2018 at 00:50, Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" rel="noreferrer" target="_blank">joel@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="m_-3581332227675505508m_-7970168827359102469gmail-h5"><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 4, 2018, 1:46 PM Vijay Kumar Banerjee <<a href="mailto:vijaykumar9597@gmail.com" rel="noreferrer" target="_blank">vijaykumar9597@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 4 July 2018 at 22:37, Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" rel="noreferrer noreferrer" target="_blank">joel@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><span class="m_-3581332227675505508m_-7970168827359102469gmail-m_3851003968265723910m_247801044271508425gmail-"><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 4, 2018, 3:06 AM Chris Johns <<a href="mailto:chrisj@rtems.org" rel="noreferrer noreferrer" target="_blank">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote:<br>
> On 4 July 2018 at 13:09, Chris Johns <<a href="mailto:chrisj@rtems.org" rel="noreferrer noreferrer noreferrer" target="_blank">chrisj@rtems.org</a><br>
> <mailto:<a href="mailto:chrisj@rtems.org" rel="noreferrer noreferrer noreferrer" target="_blank">chrisj@rtems.org</a>>> wrote:<br>
> <br>
> On 4/7/18 5:38 pm, Chris Johns wrote:<br>
> > On 4/7/18 4:52 pm, Vijay Kumar Banerjee wrote:<br>
> >><br>
> >> I'm starting this thread for discussions on the gcov support <br>
> >> in covoar.<br>
> >><br>
> >> Current status is that the code in it (like in GcovData.cc) remained untouched <br>
> >> for a long time and it had not been updated after the source tree reorganization<br>
> >> which is why it runs into segmentation<br>
> >> fault while trying to find the source files.<br>
> >><br>
> >> Joel was suggesting to copy the file gcov-io.h from the gcc<br>
> >> source after a license discussion here.<br>
> > <br>
> > What license the file's license?<br>
> <br>
> Sorry .. What is the file's license?<br>
> <br>
> GPL version 3 <br>
<br>
This license is not suitable.<br></blockquote></div></div><div dir="auto"><br></div></span><div dir="auto">It has the runtime exception and is the only file that defines the format of gcno and (need to double-check) gcda file. It does not contaminate anything.</div><div dir="auto"><br></div><div dir="auto">I don't see anyway to interpret gcno or write gcda data otherwise. </div><div dir="auto"><br></div><div dir="auto">How does llvm address this? Don't that have the same issue? </div><div dir="auto"><br></div></div></blockquote><div>llvm defines it in GCOV.h file in llvm/ProfileData/ under the license </div><div><span style="color:rgb(36,41,46);font-size:14px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">it's mentioned there that it's distributed under University of Illinois Open Source License</span><br></div><div><a href="https://github.com/llvm-mirror/llvm/blob/master/include/llvm/ProfileData/GCOV.h" rel="noreferrer noreferrer" target="_blank">https://github.com/llvm-<wbr>mirror/llvm/blob/master/<wbr>include/llvm/ProfileData/GCOV.<wbr>h </a></div></div></div></div></blockquote></div></div><div dir="auto"><br></div></div></div><div dir="auto">That would be the preferred way to get this header. Is it technically acceptable?</div><div dir="auto"><br></div><div dir="auto">Chris.. license acceptable to you?</div><span class="m_-3581332227675505508m_-7970168827359102469gmail-"><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">Ultimately we have two file formats that we have to deal with that GCC for sure defines and llvm might also.</div><span class="m_-3581332227675505508m_-7970168827359102469gmail-m_3851003968265723910m_247801044271508425gmail-"><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> > We are aiming to have all code under the RTEMS Tools under a BSD or compatible<br>
> > license. Are there other options that have a more suitable license?<br></blockquote></div></div><div dir="auto"><br></div></span><div dir="auto">Llvm would be the only option but this has the rules time exception like the RTEMS historical license so it non-viral. </div><div dir="auto"><br></div><div dir="auto">A hack would be to ensure they are installed with the RTEMS GCC by the RSB. But that would be lifting a file out of the GCC source and one from the build tree that are normally not installed. We could ask about GCC doing that.</div><span class="m_-3581332227675505508m_-7970168827359102469gmail-m_3851003968265723910m_247801044271508425gmail-"><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> > <br>
> > Also, could you please explain how gcov fits into the coverage testing?<br>
> > <br>
> <br>
> gcov is a test coverage program by gcc that generates statement-by-statement<br>
> profiling.<br>
> (<a href="https://gcc.gnu.org/onlinedocs/gcc/Gcov-Intro.html" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://gcc.gnu.org/<wbr>onlinedocs/gcc/Gcov-Intro.html</a><wbr>)<br>
<br>
Yes.<br>
<br>
> once we're able to generate gcov reports we can run graphical tools like lcov or<br>
> gcovr to generate html and xml reports with detailed coverage data.<br>
> an example of lcov report:<br>
> <a href="http://ltp.sourceforge.net/coverage/lcov/output/example/methods/iterate.c.gcov.html" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">http://ltp.sourceforge.net/<wbr>coverage/lcov/output/example/<wbr>methods/iterate.c.gcov.html</a><br>
><br>
<br>
Do you want to export gcov files from the other trace formats we handle?<br></blockquote></div></div><div dir="auto"><br></div></span><div dir="auto">Gcov reads gcda files for execution information. Rather than the executable being instrumented and writing this during execution (libgcov), covoar generates gcda files for unmodified executables using simulator trace information. But you have to read gcno files and write gcda files.</div><span class="m_-3581332227675505508m_-7970168827359102469gmail-m_3851003968265723910m_247801044271508425gmail-"><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
How does this fit into the RTEMS Tester tool?<br></blockquote></div></div><div dir="auto"><br></div></span><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">It is the path to another report format.</div><span class="m_-3581332227675505508m_-7970168827359102469gmail-m_3851003968265723910m_247801044271508425gmail-"><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Chris<br>
______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" rel="noreferrer noreferrer noreferrer" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a></blockquote></div></div></span></div>
</blockquote></div><br></div></div>
</blockquote></div></div></span></div>
</blockquote></div><br></div></div>
</blockquote></div></div></div>
</div>