Symbol Size Variance

Tue May 22 23:06:34 UTC 2018

On Tue, May 22, 2018 at 5:45 PM, Chris Johns <chrisj at rtems.org> wrote:

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

Agreed.

In this case, I think objdump just changed its format though when presented
with >1 NOP at the end of a method for padding. Unfortunately, it doesn't
do it for just 1 and the instruction we saw is not known in covaor as a
padding pattern from ld. Those are well-defined.

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

I have never seen this but believe you.

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

I am hoping that the DWARF info contains the true length and eventually
we can flag when the computed and claimed length don't match.

NOTE: Unless we incorporate objdump capability somehow, we will
be stuck with this part of the process.

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

I was reading that hoping Freddie would give us a hint on if LTO was worth
adopting after rtems5 and waf. No build changes until after that.

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

It could if it results in the code being different in a method between two
executables.

OTOH we already use -Os for analysis purposes instead of -O2. This
may just be another option that hurts coverage analysis.

I would like our test coverage to be high and work for all gcc and link
options. Just saying there may be limitations.

Or we may need to limit ourselves to source line mapping on a per executable
basis. And generate reports using gcov output if we see  methods change
between executables. I have shied away from gcov as the primary format
because I don't see how to do subexpression analysis.

  if (a == 0 || b == 1)

That's one line of source but two sub-expressions. Unless it's changed
recently, the debug info is not at a level of granularity to generate
gcov data that can tell we always too the first sub-expression.

I'm not arguing -- just saying that doing the analysis at the asm level
gives us branch information I don't think we get via source line
analysis and gcov.

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

Sounds like bad info from GCC which needs to be fixed. I would suspect
it is common across architectures.

Needs to be tracked down but doesn't derail the GSoC project. Only that
we may hit another roadblock or hurdle.

>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180522/0d834195/attachment.html>