On Thu, May 10, 2018 at 12:37 PM, Cillian O'Donnell <cpodonne...@gmail.com> wrote:
> > > On Thu, 10 May 2018, 11:48 Chris Johns, <chr...@rtems.org> wrote: > >> On 10/5/18 2:43 pm, Chris Johns wrote: >> > On 10/5/18 8:47 am, Cillian O'Donnell wrote: >> >> >> >> -------------------- >> >> GDB >> >> -------------------- >> >> >> >> (gdb) bt >> >> #0 0x00007ffff74aa428 in __GI_raise (sig=sig@entry=6) >> >> at ../sysdeps/unix/sysv/linux/raise.c:54 >> >> #1 0x00007ffff74ac02a in __GI_abort () at abort.c:89 >> >> #2 0x00007ffff7ae484d in __gnu_cxx::__verbose_terminate_handler() () >> >> from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 >> >> #3 0x00007ffff7ae26b6 in ?? () from /usr/lib/x86_64-linux-gnu/ >> libstdc++.so.6 >> >> #4 0x00007ffff7ae2701 in std::terminate() () >> >> from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 >> >> #5 0x00007ffff7ae2919 in __cxa_throw () >> >> from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 >> >> #6 0x000000000042ad4a in rld::dwarf::address::path[abi:cxx11]() >> const ( >> >> this=this@entry=0x7fffffffcc10) at ../rtemstoolkit/rld-dwarf.cpp: >> 129 >> >> #7 0x000000000042dfad in rld::dwarf::file::get_source (this=this@entry >> =0x6be568, >> >> addr=<optimized out>, source_file="unknown", >> source_line=@0x7fffffffccdc: -1) >> >> at ../rtemstoolkit/rld-dwarf.cpp:860 >> >> #8 0x000000000040d541 in Coverage::ExecutableInfo::getSourceAndLine ( >> >> this=this@entry=0x6be3c0, address=<optimized out>, line="") >> >> at ../tester/covoar/ExecutableInfo.cc:134 >> >> #9 0x000000000040a115 in Coverage::DesiredSymbols::determineSourceLines >> ( >> >> this=this@entry=0xafee70, theRanges=theRanges@entry=0xd626f0, >> >> theExecutable=0x6be3c0) at ../tester/covoar/DesiredSymbols.cc:411 >> >> #10 0x000000000040a24f in Coverage::DesiredSymbols::findSourceForUncovered >> ( >> >> this=0xafee70) at ../tester/covoar/DesiredSymbols.cc:440 >> >> #11 0x0000000000406028 in main (argc=<optimized out>, argv=<optimized >> out>) >> >> at ../tester/covoar/covoar.cc:526 >> > >> > This looks like an exception being thrown in a destructor path. >> > >> >> I can reproduce this on MacOS with the hello.cov file. Thank you for it. >> > > Cool was hoping that would work for you. Quicker debugging without me as > man in the middle. > >> >> It is not a exception in an exception or in a stack unwind path, it is an >> exception being thrown with no catch. >> >> The covoar `main()` is like C with return vales, stderr prints and exits >> or >> there are calls to exit in some paths taken from main. The RLD code >> expects a >> top level single catch which prints a message to stderr then exits. It is >> mixing >> this these two approaches which resulted in no catch. I am so use to not >> needing >> to think about it. Maybe I should look at main and clean it up. >> > > 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(). 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 https://swarminglogic.com/jotting/2014_05_lcov has more complicated reports and instructions. It even includes a shell script to make Chris happy. LOL 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. >> 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
