On Mon, Apr 16, 2018 at 4:47 PM, Vijay Kumar Banerjee < vijaykumar9...@gmail.com> wrote:
> > > On 17 April 2018 at 01:43, Cillian O'Donnell <cpodonne...@gmail.com> > wrote: > >> >> >> On 16 April 2018 at 17:46, Joel Sherrill <j...@rtems.org> wrote: >> >>> >>> >>> On Mon, Apr 16, 2018 at 2:33 AM, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> >>>> current status : >>>> the coverage is running now with rtems-test and generating the report, >>>> however, the report doesn't show any data. >>>> >>> >>> I've been lurking as you have been making progress. Now you have crossed >>> into something you probably need some hints at. Some things to check: >>> >>> + Obviously, check output for signs that something didn't happen right. >>> Anything from a path wrong, etc. The configuration has to be right to >>> point to the source code, object code, executables, etc. >>> >>> + A lot of source code has moved around since last summer. Check >>> that it is looking in the right places inside RTEMS. >>> >>> + Does the mechanism to get debug information actually work? Cillian? >>> >> >> The covoar debug option just disables the cleaning of the tempfiles to >> take a look, so it's not as powerful as it might seem :)... I always used >> gdb here so that's probably the way to go. >> >>> >>> + There is a utility named trace-converter. Make sure your qemu traces >>> have information in them. >>> >>> + Cillian probably has guidance on running it just on one test (say >>> ticker) >>> so you can see every step. >>> >>> + Check that the executables have symbolic information. "file" should >>> show if they are stripped or not. >>> >>> I recall covoar has a verbose mode which should be of use. >>> >>> Cillian .. do you have instructions on running covoar in gdb? >>> >> >> Alright so run rtems-test with --no-clean option to leave the coverage >> files lying around >> >> $HOME/development/rtems/test/test/rtems-tools/tester/rtems-test >> --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log >> --rtems-bsp=leon3_qemu --coverage --no-clean >> --rtems-builddir=$HOME/development/rtems/leon3 >> sparc-rtems5/c/leon3/testsuites/samples >> >> Then run >> >> gdb covoar >> >> from gdb prompt >> >> run -S /home/cpod/coverage_test/leon3/coverage/score.symcfg -O >> /home/cpod/coverage_test/leon3/test/score -fQEMU -Tsparc-rtems5 >> -E/home/cpod/development/rtems/test/test/vijay/rtems-tools/ >> tester/rtems/testing/coverage/Explanations.txt -c.cov -eexe -pRTEMS-5 >> /home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/test >> suites/samples/base_sp/base_sp.exe >> >> The options there are ( if you're wondering ) >> >> -c COVERAGEFILE_EXTENSION EXECUTABLE1 ... EXECUTABLE2 >> >> -v - verbose output >> -T TARGET - architecture target name >> -f FORMAT - simulator format >> (RTEMS, QEMU, TSIM or Skyeye) >> -E EXPLANATIONS - file of explanations >> -s SYMBOLS_FILE - symbols of interest >> -S SYMBOL_SET_FILE - path to symbol_sets.cfg >> -1 EXECUTABLE - executable to get symbols from >> -e EXE_EXTENSION - suffix for executables >> -c COVERAGEFILE_EXT - coverage file suffix >> -g GCNOS_LIST - list of *.gcno files >> -p PROJECT_NAME - name of the project >> -O Output_Directory - output directory default=. >> -d debug - disable cleaning of tempfiles. >> >> > maybe the problem is here . I am getting an error for the -S . Here are > the list of options that show up , capital S for symbol_set_file is not one > of them . > > Usage: /home/lunatic/development/rtems/5/bin/covoar [-v] -T TARGET -f > FORMAT [-E EXPLANATIONS] -e EXE_EXTENSION -c COVERAGEFILE_EXTENSION > EXECUTABLE1 ... EXECUTABLE2 > > -v - verbose at initialization > -T TARGET - target name > -f FORMAT - coverage file format (RTEMS, QEMU, TSIM or > Skyeye) > -E EXPLANATIONS - name of file with explanations > -s SYMBOLS_FILE - name of file with symbols of interest > -1 EXECUTABLE - name of executable to get symbols from > -e EXE_EXTENSION - extension of the executables to analyze > -c COVERAGEFILE_EXTENSION - extension of the coverage files to analyze > -g GCNOS_LIST - name of file with list of *.gcno files > -p PROJECT_NAME - name of the project > -C ConfigurationFileName - name of configuration file > -O Output_Directory - name of output directory (default=. > Is it processed by the getopts switch statement in main() but not listed in the usage? That is an easy mistake to creep in. > > >> Just trying it there, it runs into segmentation fault. So trying to >> access memory it shouldn't. >> >> Starting program: /home/cpod/covoar -S >> /home/cpod/coverage_test/leon3/coverage/score.symcfg >> -O /home/cpod/coverage_test/leon3/test/score -fQEMU -Tsparc-rtems5 >> -E/home/cpod/development/rtems/test/test/vijay/rtems-tools/ >> tester/rtems/testing/coverage/Explanations.txt -c.cov -eexe -pRTEMS-5 >> /home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/test >> suites/samples/base_sp/base_sp.exe >> Reading configuration symbol set file: /home/cpod/coverage_test/leon3 >> /coverage/score.symcfg >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00007ffff7b769bb in std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> >> >::basic_string(std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> > const&) () >> from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 >> >> Ahhh feels good to have error messages back. >> >> Oh also build covoar with no optimization and you'll have an easier time >> looking at stuff in gdb >> >> cd rtems-tools/tester/covoar >> >> vim wscript and change the '-O2' to '-O0' and then build again with waf >> and use that covoar to with gdb >> >> >>> >>> >>>> >>>> -- vijay >>>> >>> >>> >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
