On Fri, 4 May 2018, 07:51 Vijay Kumar Banerjee, <vijaykumar9...@gmail.com> wrote:
> > > On Fri, 4 May 2018, 12:17 Cillian O'Donnell, <cpodonne...@gmail.com> > wrote: > >> >> >> On Fri, 4 May 2018, 00:04 Joel Sherrill, <j...@rtems.org> wrote: >> >>> >>> >>> On Thu, May 3, 2018 at 1:45 PM, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> >>>> >>>> On 3 May 2018 at 22:58, Cillian O'Donnell <cpodonne...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, 3 May 2018, 16:23 Vijay Kumar Banerjee, < >>>>> vijaykumar9...@gmail.com> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I want to ask some things about the project to get a clear >>>>>> understanding of the objectives/milestones and current status of the >>>>>> project. I also seek advice on my Tasks/obectives. >>>>>> >>>>>> 1. The covoar has been updated to read symbols from the library and >>>>>> the next milestone is to remove covoar's dependancy on the external >>>>>> tools, >>>>>> which Chris is working on . ( Is that correct? ) >>>>>> >>>>> >>>>> Looks like it won't be necessary for gsoc, so we won't have to wait >>>>> for their removal. Chris might still have some other changes to make >>>>> though >>>>> and then we can pull master and branch off from there. >>>>> >>>> Understood. >>>> >>> >>> If it is working as is, you are OK to work on GSoC objectives. Emphasis >>> on the "working" part. >>> If something is broken right now, we want to fix it. :) >>> >>> We also want to make sure all of the previous work is merged into the >>> master. There may be >>> clean up left for this. Cillian is the best person to answer this one. >>> >>> Chris has identified things to improve covoar which are not all required >>> to be done now. >>> >>> FWIW some history which might help get some perspective. >>> >>> covoar was functional about a decade ago and driven by shell scripts >>> that are still >>> in the rtems-testing repository. That is executable evidence of the >>> work flow. I have some >>> odd figures and presentations from about the same time frame. That means >>> it predates >>> the RSB and rtems-tools. Consequently, it predates using Python and C++ >>> on the host >>> side for RTEMS tools. The shell scripts driving the process and invoking >>> covoar should >>> now be all in Python. covoar itself needs some clean up to match current >>> C++ practices. >>> >>> The use of external tools was actually recommended by a binutils >>> maintainer at the >>> time because the output of the tools is stable. That let us focus on the >>> algorithms >>> to analyse the coverage. Now we can replace the use of those where >>> possible. The >>> RTEMS Project did not use the ELF or DWARF libraries back then. >>> >>> My shell scripts only did a few subsets of code to run reports on. One >>> of the big >>> changes in the move to Python was a move to reporting on a larger number >>> of >>> small sets. For example, report coverage on score, rtems, dosfs, etc. >>> rather than >>> just "core" or "all". >>> >>> I think this is the third GSoC project to work on these tools. That >>> doesn't count >>> at least two students working on RTEMS tests to improve the actual >>> coverage. >>> >>> Hopefully Cillian's work last summer got us over the hurdle of being >>> able to generate >>> the reports using rtems-tester. Pushing to get all that merged is an >>> important and >>> critical precondition for this summer. All outstanding work should be in >>> the >>> RTEMS.org repository. >>> >>> And all your work should land there as well as soon as it is ready. :) >>> >>> >>> >>>> >>>>>> 2. after it is done , the next step,I think, would be to update the >>>>>> coverage.py and test.py with the changes in covoar. >>>>>> >>>>> >>>>> Yeah getting all the rtems tester code up to a standard that Chris >>>>> will be happy to merge it will be the next step. >>>>> >>>> So basically we wait for Chris to make the changes to covoar, needed >>>> for us to start working on coverage code to make it running and up to the >>>> standards. >>>> >>> >>> Chris can answer this. But if it works and produces coverage reports, it >>> is ready. >>> If it is broken, report it. >>> >>> All clean up and removal of external tools should not impact your >>> project if the >>> code is working now. :) >>> >>> >>>>> >>>>>> While the Covoar is being updated, shall I be looking into the >>>>>> documentations and read the code to gain better understanding? Do you >>>>>> suggest me to work on some specific task ? >>>>>> >>>>> >>>>> Understanding how covoar is working will be useful. Running covoar >>>>> with -v option and reading down through covoar.cc should help you get an >>>>> overview of what's going on. You don't need to understand every detail, >>>>> just get a general sense of it. >>>>> >>>>> okay, I'll follow this. >>>> >>> >>> There is a Word document in the covoar directory. Cillian does that flow >>> look right to you? >>> >> >> Not seeing the txt file, what's it called? >> > > https://github.com/RTEMS/rtems-tools/blob/master/tester/covoar/covoar_flow.doc > Thanks Vijay. Can't open it on a phone unfortunately. I'll have a look later. > > >>> >>> >>>> Looks like gcov is going to feature heavily in your project. So reading >>>>> up on that and understanding what state the gcov support in covoar is like >>>>> should be useful. >>>>> >>>>> Understood. I'll read about it. >>>> Thanks for the suggestions. >>>> >>> >>> My understanding is that it works (or worked) and that the reports >>> generated by >>> running "gcov" on those output files did not match the results generated >>> by >>> covoar's own reports. >>> >>> The challenge is to find one of those disagreements and let's make sure >>> covoar >>> is right. Then we can bring in the GCC guy who offered to help. >>> >>> --joel >>> >>> >>> >>>> >>>>>> Please suggest resources to gain better understanding of how coverage >>>>>> analysis works/supposed to work with the rtems tester. (I can even try >>>>>> updating the documentations with some help, this will also help me get >>>>>> better understanding ). >>>>>> >>>>>> Thank you. >>>>>> _______________________________________________ >>>>>> 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
