On Fri, 11 May 2018, 01:09 Joel Sherrill, <j...@rtems.org> wrote: > > > On Thu, May 10, 2018 at 2:15 PM, Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> Frankly, I'm totally confused at the moment. I'm not able to come up with >> a proper task list to serially go through. >> > > We are to blame for that. You have been caught in the cross-fire of us all > testing Chris' updates and discussion of future improvements. > > Ideally you can ignore this work until it is done. Testing it along the > way is > appreciated but don't let it distract you. > > > Understood.
> >> according to my understanding (and proposal), the major goals are: >> >> 1. Get the coverage analysis running again and get it merged with the >> current master repo. >> 2. Generating line coverage reports using the gcov/lcov . >> 3. get covoar generate reports on a data-centric format (as Joel >> suggested in the proposal earlier, this needs a discussion on the choice of >> format. Chris probably has some thoughts about it.) >> >> looking at the above and the current status I need to break down it into >> subtasks. Here are some of the questions that'll help me understand >> properly. >> >> 1. before the current updates to covoar, the coverage analysis was >> generating the html and txt reports (which I posted) in the previous set >> up. Is that what we're targeting to achive with the current setup? >> > > Yes. > > And ultimately not be working on anyone's personal repo with unmerged > changes. > > >> 2. The covoar is under update as Chris is working on it, there are still >> some issues there, updating the main() module is, I guess, one of them. >> This needs to be done as the first step before the tester can generate >> reports. >> > > Looks like it. It may have generated them before the fault. But I don't > know if the reports are trustworthy yet given the replacement of addr2line > with DWARF library. But when it works, yes. > > More below. > > >> >> >> On 10 May 2018 at 23:40, Joel Sherrill <j...@rtems.org> wrote: >> >>> On Thu, May 10, 2018 at 12:37 PM, Cillian O'Donnell < >>> cpodonne...@gmail.com> wrote: >>> >>>> Ahhh I see, more c++ conversion for the rest of covoar, or at least the >>>> parts called in main. That's something Vijay could do, the blueprint for >>>> the conversion is in one of Chris last patches updating covoar.cc Any >>>> objections to him doing it Joel, Chris? >>>> >>> >>> None from me. This particular issue would be higher than many of the >>> other things Chris wants changed since it manifests as a bad exit(). >>> >> I can surely try looking into it (any instructions ?). Also, Isn't Chris >> already on it ? >> >>> >>> But overall Vijay needs to get output from covar with covoar running >>> cleanly (no faults) so he can focus on gcov output and reporting >>> improvements. >>> >>> NOTE: I am still open to the idea that gcov, lcov, etc. may be able to >>> produce reports that we are completely happy with. They need to >>> at least be a working alternate. lcov output looks promising from >>> the samples I have seen: >>> >>> http://ltp.sourceforge.net/coverage/lcov/output/index.html >>> >> >> the report looks good >> > > I think it looks good for web use. > > We haven't defined solid requirements but one we know is that we have to > have > PDF (e.g. printable) and browseable reports. > > I don't know about gcov/lcov -> PDF. > > But first step is to get gcov output files, run gcov and lcov by hand, and > then > automate it. > > Hopefully, it won't be hard to review the current output versus gcov/lcov > output > and spot discrepancies. As you do more complete runs, I recall all you had > to > do is start with 100% covered methods in the current format and see if > gcov/lcov matched. > Thanks for stating it in detail. I understood what we're looking for here . > > So get output based on gcov files generated by covoar, use gcov/lcov > on them and produce nicely organized report sets, and hopefully along > the way, if there are differences in the coverage reported, we will spot > them. > Then fix those issues. > >>> >> >>> >>> https://swarminglogic.com/jotting/2014_05_lcov has more complicated >>> reports >>> and instructions. It even includes a shell script to make Chris happy. >>> LOL >>> >> thanks for the link, the inscructions are really helpful to get started. >> >>> Vijay.. my thought is that you need to get gcov files output from covoar. >>> Then automating running gcov or lcov (lcov looks nicer I think). That >>> should >>> be a nice place to be completely committed. Hopefully at this point, you >>> will be analyzing all of cpukit/ and we can find some discrepancies >>> between >>> covoar reports and lcov/gcov output. Then fix those. That's just my >>> thoughts >>> though. >>> >> +So after the covoar runs with no issues and the coverage report shows >> some data, the next work is to generate gcov output . >> + Then automating running lcov . >> > > Yep. And fix discrepancies in the reports vs existing reports. > Yeah fixing any discrepancies. > > >> >>> >>>>> I also need to figure out why the address has lost it's reference to >>>>> the source >>>>> table. >>>>> >>>>> Chris >>>>> >>>> >>>> _______________________________________________ >>>> devel mailing list >>>> devel@rtems.org >>>> http://lists.rtems.org/mailman/listinfo/devel >>>> >>> >>> >>> _______________________________________________ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >>> >> >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
