Re: Improve coverage analysis toolset
Hello , I'm currently going through the coverage code , Can you please help me understand what are the specific changes that are needed for the coverage to be running again? thanks -- vijay On 26 March 2018 at 09:30, Vijay Kumar Banerjee wrote: > 1. Yes , I plan to work on identifying the discrepancies between what > covoar reports directly and what the gcov reports based on its gcov output. > > 2. I understand this point that the scripting that generates symbol set > file, needs to be modified accordingly > > 3. I have planned to make a note and understand the requirements, changes > needed and the desired type of output during the community bonding period, > so that I have a clear picture of the objective before I start working on > it. > > The plan is to work on gcov after the existing work is merged. > Have I planned too much to work on during the summer? Should I modify my > plan in some way? Please suggest . > > Thanks > > -- vijay > > On 26 March 2018 at 03:49, Joel Sherrill wrote: > >> Just a couple of questions and planning issues. The planning issues >> are because the requirements for some of the work are likely not solid >> on our side. >> >> 1. Do you plan to work on identifying the discrepancies between >> what covoar reports directly and what gcov reports based on its >> gcov file output? I ask because I lined up someone from the GCC >> community who should be able to tell us what is not right once >> we have specific cases. >> >> 2. My recollection is that the symbol set file is generated from >> the RTEMS libraries under test. The scripting that generates this >> file will have to change also. The set of symbols changes as >> RTEMS evolves. >> >> 3. Chris has had ideas on changing the output from directly >> producing ascii and html to something else. It is on he and I >> to give you input on the actual format. >> >> Personally getting all existing work merged and it in a state >> where we can produce coverage reports again is really a >> critical thing. The previous work changed it from being >> a standalone shell script that drove things to part of the RSB >> and make it possible to have the reports based on subdirectories >> rather than one large report. >> >> I don't 'think this changes your plan except that the plan seems to >> put gcov as bonus work. It isn't discussed as work during the >> summer.It would be nice to get gcov correctness done earlier >> because that might be the best way to nice reports. For >> example, running lcov on the .gcov files produced by covoar >> might be an option. >> >> --joel >> >> >> On Sun, Mar 25, 2018 at 3:16 PM, Vijay Kumar Banerjee < >> vijaykumar9...@gmail.com> wrote: >> >>> submitted ! >>> If you find time , please give final review as well. >>> >>> Thanks >>> >>> On 26 Mar 2018 1:44 a.m., "Joel Sherrill" wrote: >>> I am out and not at a computer. Someone can double check me but I believe you can replace the PDF you upload. Unless someone answers soon, just upload it. --joel On Mar 25, 2018 2:37 PM, "Vijay Kumar Banerjee" < vijaykumar9...@gmail.com> wrote: > It's the last day before the deadline! > Please provide a final review of the proposal before submitting. > > Thanks > > -- vijay > > On 24 March 2018 at 21:37, Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> hello mentors and other developers of the community , there are only >> three days remaining to the GSoC proposal submission deadline. >> >> I request the mentors and everyone in the community who has >> experience in RTEMS, to please go through my proposal for Coverage >> Analysis >> tool improvement project , if they have time , and suggest any kind of >> improvements and changes . >> here is the link to the proposal >> https://docs.google.com/document/d/1UjCWE1ojrpDQLQ2fQqxHU0SC >> rLETlerxD6t0SOcQNLQ/edit?usp=sharing >> Thank you >> >> -- vijay >> >> On 22 March 2018 at 04:30, Joel Sherrill wrote: >> >>> Glad you have tests running. Hopefully as Cillian suggested, you can >>> fix the >>> remaining issues to see coverage. >>> >>> We certainly need to get this merged if Chris is OK with it and it >>> doesn't >>> break anything else. >>> >>> I am reviewing proposals now. Seems to be a queue. :) >>> >>> --joel >>> >>> On Wed, Mar 21, 2018 at 4:42 AM, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> Sir , I have done the changes in the proposal , based on the comments in the google doc , please review it and suggest any further changes if required Thank you , -- vijay P.S : the previous version is in parentheses , I will remove them after you review the changes . On 18 March 2018 at 16:05, Vijay Kumar Banerjee < vijayku
Re: Improve coverage analysis toolset
Sure if you want to crack at it. If you pull the ini-update branch again, I've included the other files you'll need. Now if you try and run rtems-test with coverage you will get cpod@cpod ~ $ $HOME/development/rtems/test/rtems-tools/tester/rtems-test --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log --rtems-bsp=leon3_qemu --coverage --rtems-builddir=$HOME/development/rtems/leon3 sparc-rtems5/c/leon3/testsuites/samples RTEMS Testing - Tester, 5 (80a1e6d9607e) Traceback (most recent call last): File "/home/cpod/development/rtems/test/rtems-tools/tester/rtems-test", line 40, in rt.test.run() File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/test.py", line 310, in run coverage = coverage_get_obj(opts, path_to_builddir[1]) File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/test.py", line 230, in coverage_get_obj coverage_obj = coverage.coverage_run(opts.defaults, path_to_builddir) File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/coverage.py", line 329, in __init__ self.config_map = self.macros.macros['coverage'] KeyError: 'coverage' So this is the starting point https://github.com/cillianodonnell/rtems-tools/ blob/coverage-merge/tester/rt/coverage.py#L329 The coverage options from here https://github.com/cillianodonnell/rtems-tools/blob/ini-update/tester/rtems/ testing/coverage.ini which was once https://github.com/cillianodonnell/rtems-tools/blob/ini-update/tester/rtems/ testing/coverage.mc So you'll have to dig down from coverage.py to see what needs tob e changed to parse the new format. Good luck. On 2 April 2018 at 16:22, Vijay Kumar Banerjee wrote: > Hello , > > I'm currently going through the coverage code , Can you please help me > understand what are the specific changes that are needed for the coverage > to be running again? > thanks > > -- vijay > > On 26 March 2018 at 09:30, Vijay Kumar Banerjee > wrote: > >> 1. Yes , I plan to work on identifying the discrepancies between what >> covoar reports directly and what the gcov reports based on its gcov output. >> >> 2. I understand this point that the scripting that generates symbol set >> file, needs to be modified accordingly >> >> 3. I have planned to make a note and understand the requirements, changes >> needed and the desired type of output during the community bonding period, >> so that I have a clear picture of the objective before I start working on >> it. >> >> The plan is to work on gcov after the existing work is merged. >> Have I planned too much to work on during the summer? Should I modify my >> plan in some way? Please suggest . >> >> Thanks >> >> -- vijay >> >> On 26 March 2018 at 03:49, Joel Sherrill wrote: >> >>> Just a couple of questions and planning issues. The planning issues >>> are because the requirements for some of the work are likely not solid >>> on our side. >>> >>> 1. Do you plan to work on identifying the discrepancies between >>> what covoar reports directly and what gcov reports based on its >>> gcov file output? I ask because I lined up someone from the GCC >>> community who should be able to tell us what is not right once >>> we have specific cases. >>> >>> 2. My recollection is that the symbol set file is generated from >>> the RTEMS libraries under test. The scripting that generates this >>> file will have to change also. The set of symbols changes as >>> RTEMS evolves. >>> >>> 3. Chris has had ideas on changing the output from directly >>> producing ascii and html to something else. It is on he and I >>> to give you input on the actual format. >>> >>> Personally getting all existing work merged and it in a state >>> where we can produce coverage reports again is really a >>> critical thing. The previous work changed it from being >>> a standalone shell script that drove things to part of the RSB >>> and make it possible to have the reports based on subdirectories >>> rather than one large report. >>> >>> I don't 'think this changes your plan except that the plan seems to >>> put gcov as bonus work. It isn't discussed as work during the >>> summer.It would be nice to get gcov correctness done earlier >>> because that might be the best way to nice reports. For >>> example, running lcov on the .gcov files produced by covoar >>> might be an option. >>> >>> --joel >>> >>> >>> On Sun, Mar 25, 2018 at 3:16 PM, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> submitted ! If you find time , please give final review as well. Thanks On 26 Mar 2018 1:44 a.m., "Joel Sherrill" wrote: > I am out and not at a computer. Someone can double check me but I > believe you can replace the PDF you upload. > > Unless someone answers soon, just upload it. > > --joel > > On Mar 25, 2018 2:37 PM, "Vijay Kumar Banerjee" < > vijaykumar9...@gmail.com> wrote: > >> It's the last day before the deadline! >> Please provide a final review of the proposal be
Re: Improve coverage analysis toolset
On 03/04/2018 02:10, Cillian O'Donnell wrote: > Sure if you want to crack at it. > > If you pull the ini-update branch again, I've included the other files you'll > need. > > Now if you try and run rtems-test with coverage you will get > > cpod@cpod ~ $ $HOME/development/rtems/test/rtems-tools/tester/rtems-test > --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log > --rtems-bsp=leon3_qemu --coverage > --rtems-builddir=$HOME/development/rtems/leon3 > sparc-rtems5/c/leon3/testsuites/samples > RTEMS Testing - Tester, 5 (80a1e6d9607e) > Traceback (most recent call last): > File "/home/cpod/development/rtems/test/rtems-tools/tester/rtems-test", line > 40, in > rt.test.run() > File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/test.py", line > 310, in run > coverage = coverage_get_obj(opts, path_to_builddir[1]) > File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/test.py", line > 230, in coverage_get_obj > coverage_obj = coverage.coverage_run(opts.defaults, path_to_builddir) > File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/coverage.py", > line 329, in __init__ > self.config_map = self.macros.macros['coverage'] I would not access the 'macros' dictionary directly like this. It circumvents the map support. There is '__getitem__' support on the class which is better but still raises an exception on an index error. You can ask if a key is present and the 'get()' interface returns 'None' if not found. > KeyError: 'coverage' Can we please create new threads for new topics? Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
