<div dir="auto"><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">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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/raise.c:54<br>
>> #1  0x00007ffff74ac02a in __GI_abort () at abort.c:89<br>
>> #2  0x00007ffff7ae484d in __gnu_cxx::__verbose_terminate_handler() ()<br>
>>    from /usr/lib/x86_64-linux-gnu/libstdc++.so.6<br>
>> #3  0x00007ffff7ae26b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6<br>
>> #4  0x00007ffff7ae2701 in std::terminate() ()<br>
>>    from /usr/lib/x86_64-linux-gnu/libstdc++.so.6<br>
>> #5  0x00007ffff7ae2919 in __cxa_throw ()<br>
>>    from /usr/lib/x86_64-linux-gnu/libstdc++.so.6<br>
>> #6  0x000000000042ad4a in rld::dwarf::address::path[abi:cxx11]() const (<br>
>>     this=this@entry=0x7fffffffcc10) at ../rtemstoolkit/rld-dwarf.cpp: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:860<br>
>> #8  0x000000000040d541 in Coverage::ExecutableInfo::getSourceAndLine (<br>
>>     this=this@entry=0x6be3c0, address=<optimized out>, line="")<br>
>>     at ../tester/covoar/ExecutableInfo.cc:134<br>
>> #9  0x000000000040a115 in Coverage::DesiredSymbols::determineSourceLines (<br>
>>     this=this@entry=0xafee70, theRanges=theRanges@entry=0xd626f0,<br>
>>     theExecutable=0x6be3c0) at ../tester/covoar/DesiredSymbols.cc:411<br>
>> #10 0x000000000040a24f in Coverage::DesiredSymbols::findSourceForUncovered (<br>
>>     this=0xafee70) at ../tester/covoar/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 dir="auto">Cool was hoping that would work for you. Quicker debugging without me as man in the middle.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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><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 dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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></div>