Symbol Size Variance

[Joel Sherrill]

On Mon, May 21, 2018, 7:44 PM Chris Johns <chrisj at rtems.org> wrote:

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

These are important to look into but should almost certainly not have
anything to do with the bugs I described.

Do they appear on other architectures?

We.need to.move these questions to the binutils list? Only they can answer
these.

>
> 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.
>
> chrisj at rtems.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180522/6c094b18/attachment-0002.html>