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

Wed May 9 20:47:56 UTC 2018

Just running covoar there, we seem to be running into some problems at the
source line lookup stage

cpod at cpod ~/development/rtems/leon3 $ covoar -S
/home/cpod/development/rtems/test/rtems-tools/tester/rtems/testing/coverage/score-symbols.ini
-O /home/cpod/coverage_test/test/score
-E/home/cpod/development/rtems/test/rtems-tools/tester/rtems/testing/coverage/Explanations.txt
-p RTEMS-5 -v sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
Processing multiple executable/coverage file pairs
Coverage Format : html
Target          : sparc-rtems5

Coverage file sparc-rtems5/c/leon3/testsuites/samples/hello/hello.cov for
executable: sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
Loading symbol sets:
/home/cpod/development/rtems/test/rtems-tools/tester/rtems/testing/coverage/score-symbols.ini
 Symbol set: score
 Loading library: sparc-rtems5/c/leon3/cpukit/score/libscore.a
cache:load-sym: object files: 192
cache:load-sym: symbols: 382
Analyzing 382 symbols
Extracting information from:
sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
Created unified coverage map for _RTEMS_Lock_allocator (0x0 - 0x13)
Created unified coverage map for _RTEMS_Unlock_allocator (0x0 - 0x13)
Created unified coverage map for _API_Mutex_Lock (0x0 - 0x2f)
Created unified coverage map for _API_Mutex_Unlock (0x0 - 0x2f)
Created unified coverage map for _Chain_Initialize (0x0 - 0x4f)
Created unified coverage map for _Freechain_Initialize (0x0 - 0x33)
Created unified coverage map for _Freechain_Get (0x0 - 0x77)
Created unified coverage map for _Freechain_Put (0x0 - 0x27)
Created unified coverage map for _Heap_Allocate_aligned_with_boundary (0x0
- 0x23f)
................
...............
...............
Branch always taken found in_Workspace_Handler_initialization (0x4000ab8c -
0x4000ab8f)
Branch never taken found in _Workspace_Handler_initialization (0x1073785764
- 0x1073785767)
Branch never taken found in _Workspace_Handler_initialization (0x1073785776
- 0x1073785779)
Calculate statistics
Looking up source lines for uncovered ranges and branches
Looking up source lines for uncovered ranges in CSWTCH.1
terminate called after throwing an instance of 'rld::error'
Aborted

--------------------
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

I'll attach a trace file I'm using to debug, hopefully you can use this. It
has to go with hello.exe in the build directory

All the best,

Cillian.

On 8 May 2018 at 06:09, Chris Johns <chrisj at rtems.org> wrote:

> Hi,
>
> This is a wrap up patch of all the issues that have been raise. Thanks to
> the excellent debugging and teamwork in finding the linking issue on Linux,
> that is a really strange one to trip over.
>
> The patches:
>
> - Add a DWARF framework to the rtemstoolkit to access the
>   source file and line given an address in an executable. This allows
>   us to remove exec'ing addr2line in covoar.
>
> - Add producer support to rtems-exe-info to list the compilers used
>   to build the executables plus list the common flags and optionally
>   list all the object files with the flags that are not common.
>
> - Clean up exception handling in destructors in some places. This
>   avoids a terminate if an exception is thrown in an exception
>   unwind.
>
> Changes since v1:
>
> - Fix rld::path::path_abs() to not walk above the root directory.
>
> - Fix a memory issue with the dwarf_srcfiles(). The libdwarf we are
>   using manages all memory and does not need to have it dealloced
>   while the man pages state it should be.
>
> - Add producer support to collect and manage CU producer attributes.
>
> - Remove libgen.h from covoar and use RLD path. I have not tested
>   those changes.
>
> I recommend anyone shipping RTEMS executables to run rtems-exe-info over
> your executables and have a look. It will let you know if you are using
> the same compiler in all parts as well as listing the machine flags
> used to control GCC.
>
> 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/20180509/6b42788c/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello.cov
Type: application/octet-stream
Size: 18668 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180509/6b42788c/attachment-0002.obj>