Symbol Size Variance

[Joel Sherrill]

Hi

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)

I started looking at the smallest one (capture.exe). It looks to
follow the pattern one expects when there is no padding needed
between it and the next method. [1]

Then I looked at ticker.dmp since it was one of the largest ones.
It puts a line with "..." at the end of the method and there was
a fairly large gap (0x360 - 0x380 - 4) which is 0x1c bytes of gap.

BUG 1: It looks like the output of objdump has changed its output
a bit and ObjdumpProcessor.cc is not recognizing the "..." line as
the end of a method. If you fix this issue, I suspect the ones ~80
bytes will be the right size.

Now let's move on to another one with a smaller size difference.
It is also an easier fix.  Look at base_sp.dmp. The last instruction is:

4000c5dc: 00 00 00 00 unimp  0

Now look in Target_sparc.cc in IsNopLine(). That "instruction" is
not recognized as a nop.

BUG 2: Add logic to Target_sparc.cc to process that line as a nop.

As a final check, I looked at cxx_iostream.dmp which is 8 bytes
(e.g. 2 instructions) of padding. it uses the "..." line to indicate
padding.

So there's two bugs to fix which should address the situation.
The bugs are important but it is just as important that you understand
the process of how I tracked down what was going wrong. These
two are common problems.

  (a) issues processing the objdump
  (b) not understanding a nop

Once you get all the input into the C++ structures, life tends to
just be magically delicious. :)

[1] Padding is inserted by ld when linking the program to put
the first part of a function on a cache line boundary.

--joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180521/ad27a482/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmp_sizes
Type: application/octet-stream
Size: 1765 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180521/ad27a482/attachment.obj>