V2 Add DWARF support to the rtemstoolkit and put it to use.

[Joel Sherrill]

On Thu, May 10, 2018 at 12:37 PM, Cillian O'Donnell <cpodonnell8 at gmail.com>
wrote:

>
>
> On Thu, 10 May 2018, 11:48 Chris Johns, <chrisj at 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 at 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 at entry=0x7fffffffcc10) at ../rtemstoolkit/rld-dwarf.cpp:
>> 129
>> >> #7  0x000000000042dfad in rld::dwarf::file::get_source (this=this at 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 at entry=0x6be3c0, address=<optimized out>, line="")
>> >>     at ../tester/covoar/ExecutableInfo.cc:134
>> >> #9  0x000000000040a115 in Coverage::DesiredSymbols::determineSourceLines
>> (
>> >>     this=this at entry=0xafee70, theRanges=theRanges at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180510/dd85a64d/attachment-0002.html>