On 14 May 2018 at 23:37, Joel Sherrill <j...@rtems.org> wrote: > > > On Mon, May 14, 2018 at 12:43 PM, Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> On 14 May 2018 at 21:21, Joel Sherrill <j...@rtems.org> wrote: >> >>> >>> >>> On Mon, May 14, 2018 at 10:19 AM, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> >>>> Hello, >>>> >>>> The coverage report is showing some data now (txt only). There is still >>>> some work needed to be done for it to get merged with the main repo. As it >>>> depends on the ongoing work on the covoar.cc and coverage.py, meanwhile I >>>> want to get started with the gcov support in covoar as I already have some >>>> coverage data in txt format to compare with . >>>> >>>> I would like to know the following points to get started: >>>> >>>> 1. What is the current state of the gcov support in covoar. I can >>>> see work on GcovData and GcovFunction data in covoar, what's the current >>>> status of it ? >>>> >>> >>> Technically unknown, potentially bit rotted. >>> >> Seems like it will take some time before it starts making sense . >> > > Maybe. Since you can produce coverage reports now, I am betting it > will likely work quickly. :) > Hopefully.
> > >> >> >>> >>> >>>> >>>> 2. Did it use to run at some point? seeing it in action will be >>>> very helpful. >>>> >>> >>> It used to produce .gcov files that could be processed by gcov and >>> produce reports. >>> >> Then our very first objective is to get the .gcov file output only then >> can we proceed with the discripancies >> > > Yes. > > Use the same test executables and symbols of interest. > > I suspect you have been looking at a report for the same test exe and the > same methods. > Just check that the report from gcov matches. If it doesn't, then we have > a small test case. > Yeah that will be the approach. > > >> >>> Once you started to compare the reports to the native reports from >>> covoar, you would sometimes see places that covoar thought some code was >>> executed that did not show up in the gcov generated report. When I >>> investigated, I got far enough to know we had executed the code in question. >>> >>> >>>> >>>> 3. What are the listed blockers rn ? Other than the reliability of >>>> the report . >>>> >>> >>> That's it. Get it working and then let's work on automation, use of >>> lcov, etc. Along the way, I am sure we will spot the difference in >>> reporting. Then that will have to be fixed. >>> >>> >>>> 4. are there any tickets related to gcov? >>>> >>> >>> Not from RTEMS' perspective. >>> >>> One challenge we had previously is that the .gcov file format was only >>> documented in the header file. That was why I asked for someone from the >>> gcc community to help us once we spot difference. Hopefully they can help >>> us figure out what is wrong with the file covoar is producing. >>> >> >>>> Please add any suggestions or references that might help me get started >>>> properly . >>>> >>> > https://gcc.gnu.org/onlinedocs/gcc/Gcov-Data-Files.html is an overview > from a gcc user's perspective. > > The details are in the gcc source code. This should be the current version > of the gcov file: > > https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov-io.h > Thanks for the links > > > I don't remember a comment in the version in covoar specifying that the > format could change > with GCC versions. Maybe that's the gcno data and not the coverage data. > > This needs to be looked into properly to undertsand how the versions impact the report generation. > Randomly found this tool which looks like another option for more > reports/analysis once gcov > files are available: > > https://gcovr.com/guide.html > > it says XML reports! Looks like we have some cool options to try out once we get the initial steps done. > >>>> Thank you, >>>> >>> > R > >> >>>> Vijay >>>> >>>> >>>> >>> >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel