<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Mon, May 21, 2018, 7:44 PM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">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 22/5/18 9:12 am, Joel Sherrill wrote:<br>
> <br>
> Attached is a shell script (pokes Chris) which calculates the size of <br>
> the specified symbol across a set of .exe files. <br>
> <br>
> [joel@rtbf64c samples]$ /tmp/cmp_sizes -a sparc -s<br>
> _Workspace_Allocate_or_fatal_error *.exe<br>
> Size report for _Workspace_Allocate_or_fatal_error<br>
>          base_sp.exe - 0x4000c5a0 - 0x4000c5e0 (64)<br>
>          capture.exe - 0x400162a0 - 0x400162dc (60)<br>
>           cdtest.exe - 0x4001e6c4 - 0x4001e700 (60)<br>
>     cxx_iostream.exe - 0x4005cbdc - 0x4005cc20 (68)<br>
>           fileio.exe - 0x40020720 - 0x4002075c (60)<br>
>            hello.exe - 0x4000ac50 - 0x4000aca0 (80)<br>
>          minimum.exe - 0x40006240 - 0x40006280 (64)<br>
>            nsecs.exe - 0x4000c668 - 0x4000c6c0 (88)<br>
>         paranoia.exe - 0x4001426c - 0x400142c0 (84)<br>
>           ticker.exe - 0x4000d328 - 0x4000d380 (88)<br>
>        unlimited.exe - 0x4000cc0c - 0x4000cc60 (84)<br>
> <br>
> NOTE: Each SPARC instruction is ALWAYS 4 bytes. That will be<br>
> important as we look at instruction addresses.<br>
> <br>
> I objdump'ed (sparc-rtems5-objdump -S) each exe as I got to it in<br>
> the analysis. ( sparc-rtems5-objdump -S XXX.exe >XXX.dmp)<br>
<br>
The following is not something for the GSoC tasks and I report them here and now<br>
so we can keep them in mind.<br>
<br>
Binutils' objdump like addr2line uses the DWARF information held in the ELF<br>
file. My close inspection of the DWARF data in the exe files we are creating<br>
leave me with some concerns.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">These are important to look into but should almost certainly not have anything to do with the bugs I described.</div><div dir="auto"><br></div><div dir="auto">Do they appear on other architectures?</div><div dir="auto"><br></div><div dir="auto">We.need to.move these questions to the binutils list? Only they can answer these.</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>
Specifically:<br>
<br>
$ sparc-rtems5-readelf --debug-dump \<br>
   sparc-rtems5/c/erc32/testsuites/samples/cdtest.exe > /dev/null<br>
<br>
generates 3247 warnings of ...<br>
<br>
 readelf: Warning: There is a hole [0x41f86 - 0x41f9c] in .debug_loc section.<br>
<br>
I have not tracked down what this means. The elftoolchain's libdwarf does not<br>
report such issues however it is not parsing all the debug info data so may not<br>
be seeing it.<br>
<br>
I am seeing 583 instances of "Extended opcode 2: set Address to 0x0" using:<br>
<br>
$ sparc-rtems5-readelf --debug-dump \<br>
   sparc-rtems5/c/erc32/testsuites/samples/cdtest.exe 2>&1 | \<br>
   grep "Extended opcode 2: set Address to 0x0"<br>
<br>
If you grep for just "Extended opcode 2: set Address to" you will see the<br>
address being correctly set in the line info DWARF program sequence for most<br>
entries however the setting to 0x0 seems wrong to me as the DWARF v5 standard<br>
section "6.2.5 The Line Number Program" states for line number info:<br>
<br>
 Within a sequence, addresses and operation pointers may only increase.<br>
<br>
The output from above shows the line address being set to 0 after being set to a<br>
non-zero value.<br>
<br>
I do not know if these issues are specific to the SPARC architecture or an<br>
option we use like section text and data.<br>
<br>
It is difficult to judge what effect these issues have on the coverage analysis.<br>
I feel we need this data to be accurate in-order to trust the results our<br>
coverage tool creates.<br>
<br>
I need to look into binutils to see how this is being handled and if this is<br>
normal and expected behavior.<br>
<br><a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>
</blockquote></div></div></div>