Symbol Size Variance

[Chris Johns]

On 22/5/18 9:12 am, Joel Sherrill wrote:
> 
> Attached is a shell script (pokes Chris) which calculates the size of 
> the specified symbol across a set of .exe files. 
> 
> [joel at rtbf64c samples]$ /tmp/cmp_sizes -a sparc -s
> _Workspace_Allocate_or_fatal_error *.exe
> Size report for _Workspace_Allocate_or_fatal_error
>          base_sp.exe - 0x4000c5a0 - 0x4000c5e0 (64)
>          capture.exe - 0x400162a0 - 0x400162dc (60)
>           cdtest.exe - 0x4001e6c4 - 0x4001e700 (60)
>     cxx_iostream.exe - 0x4005cbdc - 0x4005cc20 (68)
>           fileio.exe - 0x40020720 - 0x4002075c (60)
>            hello.exe - 0x4000ac50 - 0x4000aca0 (80)
>          minimum.exe - 0x40006240 - 0x40006280 (64)
>            nsecs.exe - 0x4000c668 - 0x4000c6c0 (88)
>         paranoia.exe - 0x4001426c - 0x400142c0 (84)
>           ticker.exe - 0x4000d328 - 0x4000d380 (88)
>        unlimited.exe - 0x4000cc0c - 0x4000cc60 (84)
> 
> NOTE: Each SPARC instruction is ALWAYS 4 bytes. That will be
> important as we look at instruction addresses.
> 
> I objdump'ed (sparc-rtems5-objdump -S) each exe as I got to it in
> the analysis. ( sparc-rtems5-objdump -S XXX.exe >XXX.dmp)

The following is not something for the GSoC tasks and I report them here and now
so we can keep them in mind.

Binutils' objdump like addr2line uses the DWARF information held in the ELF
file. My close inspection of the DWARF data in the exe files we are creating
leave me with some concerns.

Specifically:

$ sparc-rtems5-readelf --debug-dump \
   sparc-rtems5/c/erc32/testsuites/samples/cdtest.exe > /dev/null

generates 3247 warnings of ...

 readelf: Warning: There is a hole [0x41f86 - 0x41f9c] in .debug_loc section.

I have not tracked down what this means. The elftoolchain's libdwarf does not
report such issues however it is not parsing all the debug info data so may not
be seeing it.

I am seeing 583 instances of "Extended opcode 2: set Address to 0x0" using:

$ sparc-rtems5-readelf --debug-dump \
   sparc-rtems5/c/erc32/testsuites/samples/cdtest.exe 2>&1 | \
   grep "Extended opcode 2: set Address to 0x0"

If you grep for just "Extended opcode 2: set Address to" you will see the
address being correctly set in the line info DWARF program sequence for most
entries however the setting to 0x0 seems wrong to me as the DWARF v5 standard
section "6.2.5 The Line Number Program" states for line number info:

 Within a sequence, addresses and operation pointers may only increase.

The output from above shows the line address being set to 0 after being set to a
non-zero value.

I do not know if these issues are specific to the SPARC architecture or an
option we use like section text and data.

It is difficult to judge what effect these issues have on the coverage analysis.
I feel we need this data to be accurate in-order to trust the results our
coverage tool creates.

I need to look into binutils to see how this is being handled and if this is
normal and expected behavior.

Chris