Hi There is a bug in the DWARF DIE class whIch crashes covoar and returns a -9. I have a fix but I have no computer access to finishes the changes and push the fix. I hope to be back sometime next week. I am sorry about this.
Chris > On 21 Jul 2018, at 10:19 am, Vijay Kumar Banerjee <vijaykumar9...@gmail.com> > wrote: > >> On Fri, Jul 20, 2018, 10:08 PM Joel Sherrill <j...@rtems.org> wrote: >> >> >>> On Fri, Jul 20, 2018 at 9:14 AM, Gedare Bloom <ged...@rtems.org> wrote: >>> On Thu, Jul 19, 2018 at 6:29 PM, Vijay Kumar Banerjee >>> <vijaykumar9...@gmail.com> wrote: >>> > Hello, >>> > >>> > I used the following command >>> > >>> > ==================== >>> > $HOME/development/rtems/test/rtems-tools/tester/rtems-test \ >>> > --rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log \ >>> > --no-clean --coverage=score --rtems-bsp=leon3-qemu-cov \ >>> > /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites >>> > --debug-trace=cov >>> > ==================== >>> > >>> > and I'm getting the following error >>> > >>> > =================== >>> > error: coverage: covoar failure:: -9 >>> > =================== >>> > >>> >>> What does error code -9 mean from covoar? >>> >>> Does it make any progress at all? >> >> Can you capture the command line used to invoke covoar and >> run it in gdb? That's an odd error message. covoar is usually >> good at printing something useful. It was written to be paranoid. > > yes I'm trying to run it in gdb, the laptop > freezes for a long time and I have to > restart it, I'll give it more time tommorow > and let it take as much time as it wants > > It runs fine for samples/ so we're searching > for a small test case where it trips, so > I'll run it separately for each set of tests, > like benchmarks/ , fstests/ ... > >> >>> >>> > This, however, runs fine for samples/ >>> > >>> >>> does this command work for you without using the cov options? >>> >>> > I think this will probably be on hold as Chris seems to be >>> > on a break, meanwhile, I want to do a wrapup work on >>> > the non-gcov coverage reports, I seek suggestions/advice >>> > for the same. >>> > >>> > The current state is that the coverage reports can be generated >>> > for one symbol-set only, There's a ticket for the support of >>> > generating separate reports of multiple sets from covoar. >>> > >>> > https://devel.rtems.org/ticket/3441 >> >> I thought originally that the Python would invoke covoar multiple >> times. It was slower but that was how it was originally designed. >> Is there no support in the Python for doing this? > > I was building it in a way that the script invokes > covoar multiple times, but Chris' modifications > to covoar added support for reading multiple symbol-sets > after which I changed the coverage script. > > If we're planning to have this support in > the python script untill covoar is updated, > then I can add it. > >> >>> >>> > >>> > Please let me know of any suggestions including suggestions >>> > regarding documentation as Coverage needs more >>> > documentation. >>> > >>> >>> What is the existing documentation for coverage? >> >> That's an important part of reproducability. >> >>> >>> > Thanks >>> > -- vijay >>> > >>> > _______________________________________________ >>> > 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