<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 10, 2018 at 12:37 PM, Cillian O'Donnell <span dir="ltr"><<a href="mailto:cpodonnell8@gmail.com" target="_blank">cpodonnell8@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="gmail-h5"><div><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 10 May 2018, 11:48 Chris Johns, <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/5/18 2:43 pm, Chris Johns wrote:<br>
> On 10/5/18 8:47 am, Cillian O'Donnell wrote:<br>
>><br>
>> --------------------<br>
>> GDB<br>
>> --------------------<br>
>><br>
>> (gdb) bt<br>
>> #0  0x00007ffff74aa428 in __GI_raise (sig=sig@entry=6)<br>
>>     at ../sysdeps/unix/sysv/linux/<wbr>raise.c:54<br>
>> #1  0x00007ffff74ac02a in __GI_abort () at abort.c:89<br>
>> #2  0x00007ffff7ae484d in __gnu_cxx::__verbose_<wbr>terminate_handler() ()<br>
>>    from /usr/lib/x86_64-linux-gnu/<wbr>libstdc++.so.6<br>
>> #3  0x00007ffff7ae26b6 in ?? () from /usr/lib/x86_64-linux-gnu/<wbr>libstdc++.so.6<br>
>> #4  0x00007ffff7ae2701 in std::terminate() ()<br>
>>    from /usr/lib/x86_64-linux-gnu/<wbr>libstdc++.so.6<br>
>> #5  0x00007ffff7ae2919 in __cxa_throw ()<br>
>>    from /usr/lib/x86_64-linux-gnu/<wbr>libstdc++.so.6<br>
>> #6  0x000000000042ad4a in rld::dwarf::address::path[abi:<wbr>cxx11]() const (<br>
>>     this=this@entry=<wbr>0x7fffffffcc10) at ../rtemstoolkit/rld-dwarf.cpp:<wbr>129<br>
>> #7  0x000000000042dfad in rld::dwarf::file::get_source (this=this@entry=0x6be568,<br>
>>     addr=<optimized out>, source_file="unknown", source_line=@0x7fffffffccdc: -1)<br>
>>     at ../rtemstoolkit/rld-dwarf.cpp:<wbr>860<br>
>> #8  0x000000000040d541 in Coverage::ExecutableInfo::<wbr>getSourceAndLine (<br>
>>     this=this@entry=0x6be3c0, address=<optimized out>, line="")<br>
>>     at ../tester/covoar/<wbr>ExecutableInfo.cc:134<br>
>> #9  0x000000000040a115 in Coverage::DesiredSymbols::<wbr>determineSourceLines (<br>
>>     this=this@entry=0xafee70, theRanges=theRanges@entry=<wbr>0xd626f0,<br>
>>     theExecutable=0x6be3c0) at ../tester/covoar/<wbr>DesiredSymbols.cc:411<br>
>> #10 0x000000000040a24f in Coverage::DesiredSymbols::<wbr>findSourceForUncovered (<br>
>>     this=0xafee70) at ../tester/covoar/<wbr>DesiredSymbols.cc:440<br>
>> #11 0x0000000000406028 in main (argc=<optimized out>, argv=<optimized out>)<br>
>>     at ../tester/covoar/covoar.cc:526<br>
> <br>
> This looks like an exception being thrown in a destructor path.<br>
> <br>
<br>
I can reproduce this on MacOS with the hello.cov file. Thank you for it.<br></blockquote></div></div><div dir="auto"><br></div></div></div><div dir="auto">Cool was hoping that would work for you. Quicker debugging without me as man in the middle.</div><span class="gmail-"><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It is not a exception in an exception or in a stack unwind path, it is an<br>
exception being thrown with no catch.<br>
<br>
The covoar `main()` is  like C with return vales, stderr prints and exits or<br>
there are calls to exit in some paths taken from main. The RLD code expects a<br>
top level single catch which prints a message to stderr then exits. It is mixing<br>
this these two approaches which resulted in no catch. I am so use to not needing<br>
to think about it. Maybe I should look at main and clean it up.<br></blockquote></div></div><div dir="auto"><br></div></span><div dir="auto">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?</div></div></blockquote><div><br></div><div>None from me. This particular issue would be higher than many of the</div><div>other things Chris wants changed since it manifests as a bad exit().</div><div><br></div><div>But overall Vijay needs to get output from covar with covoar running</div><div>cleanly (no faults) so he can focus on gcov output and reporting</div><div>improvements.</div><div><br></div><div>NOTE: I am still open to the idea that gcov, lcov, etc. may be able to</div><div>produce reports that we are completely happy with. They need to</div><div>at least be a working alternate. lcov output looks promising from </div><div>the samples I have seen:</div><div><br></div><div><a href="http://ltp.sourceforge.net/coverage/lcov/output/index.html">http://ltp.sourceforge.net/coverage/lcov/output/index.html</a><br></div><div><br></div><div><a href="https://swarminglogic.com/jotting/2014_05_lcov">https://swarminglogic.com/jotting/2014_05_lcov</a> has more complicated reports</div><div>and instructions. It even includes a shell script to make Chris happy. LOL<br></div><div><br></div><div>Vijay.. my thought is that you need to get gcov files output from covoar.</div><div>Then automating running gcov or lcov (lcov looks nicer I think). That should</div><div>be a nice place to be completely committed. Hopefully at this point, you</div><div>will be analyzing all of cpukit/ and we can find some discrepancies between</div><div>covoar reports and lcov/gcov output. Then fix those.  That's just my thoughts</div><div>though.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><span class="gmail-"><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I also need to figure out why the address has lost it's reference to the source<br>
table.<br>
<br>
Chris<br>
</blockquote></div></div></span></div>
<br>______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br></blockquote></div><br></div></div>