Symbol Size Variance

[Chris Johns]

On 22/5/18 11:14 pm, Joel Sherrill wrote:
> On Mon, May 21, 2018, 7:44 PM Chris Johns <chrisj at rtems.org
> <mailto: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.

Sure this is probability correct but you or I cannot prove this. What concerns
me most is objdump says nothing so it is natural for us to consider what it
presents as accurate when it may not be, it may be an approximation. For a
command line tool to investigate an ELF file this would seem reasonable because
the user is after some detail however this is not the case in our use.

The output you are parsing is derived from the DWARF info and that needs to be
correct but I am suspicious it is not. For example the line details for mutex.c
in the hello.exe Cillian sent me is clearly wrong, the line program's location
opcode sets the address to 0x0 while mutex.c in cdtest.exe I built locally is
correctly setting the address. This points to the linker.

You are attempting to correlate function lengths that do not match across
different executable files looking for a pattern to match against and all I am
saying is there may not be one you can find because of a bug elsewhere. As a
result this issue will appear over and over and frustrate you.

There is also this recent thread on gcc's list:

https://gcc.gnu.org/ml/gcc/2018-05/msg00083.html

which discusses issues with -fdata-sections and -ffunction-sections. The thread
is about LTO however the discussion also covers -fdata-sections and
-ffunction-sections when not using LTO. Has adding these options changed
something? There is discussion about a patch for binutils I have not tracked
down and we should do this as well.

FWIW the discussion also highlights that -fdata-sections and -ffunction-sections
may not be the best options for some RISC architectures and LTO is better at
reducing the overall executable size. I suspect LTO will cause covoar issues as
well.

> 
> Do they appear on other architectures?
> 

I have not looked. The gcc thread is about the ARM architecture so it may.

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

Yes. I would like to figure out what is a real issue and what is something I
have to handle better or I need to understand better.

Chris