Symbol Size Variance

Wed May 23 08:32:59 UTC 2018

On 23/5/18 11:06 am, Joel Sherrill wrote:
> On Tue, May 22, 2018 at 5:45 PM, Chris Johns <chrisj at rtems.org
> <mailto: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>
>     > <mailto: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. 
>

I believe this is a bug of some form in the linker where unused sections of code
in a CU are being remove but some of the debug info is being left and this
results in the address fields of that info not being updated after relocation
because there is no address in the .text section to map too.

I have coded around this for now. I think what I have is OK but it is hard to say.

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

I have only been looking at the line info and with that you can see the
continuous address range the CU spans. The DWARF CU attributes of pc_low and
pc_high is not consistently present. With line information I can determine the
starting address of the highest line of code present but not the end.

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

Which capabilities are you referring too?

> 
> 
>     There is also this recent thread on gcc's list:
> 
>     https://gcc.gnu.org/ml/gcc/2018-05/msg00083.html
>     <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. 
> 

I think the RSB has options to enable LTO. It have not tried it in a while.

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

The linker can do this now and the compiler options will not matter.

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

I think this will be the case.

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

My approach is work through the detail and expose any limitations and see how
they can be resolved.

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

I understand, the line info is just step to removed exec'ing to addr2line. I
think we will need to integrate Capstone [1] to get to the assembler level of
detail and stop exec'ing objdump.

Chris

[1] https://www.capstone-engine.org/