Re: stabs/dwarf size comparison on CSiBE (Was: stabs support in binutils, gcc, and gdb)

[Steven Bosscher <stevenb.gcc@gmail.com>]

On Tue, Jan 15, 2013 at 6:53 PM, Jan Kratochvil wrote:
> On Tue, 15 Jan 2013 11:09:46 +0100, Steven Bosscher wrote:
>> Unless someone can shoot holes in this test approach,
>
> While the sum of *.o files sizes may make sense in some cases I would find
> more useful to measure it only for the final executables and after they have
> been processed by dwz.
>
> Besides dwz also .debug_* sections relocations have large size and all these
> relocations get removed in the final executable.

I know, but that's not how CSiBE is set up. My numbers bias against
DWARF for the reasons you mention, and the size of the DWARF info
*still* is not nearly an order of magnitude greater than stabs info.

I've posted these numbers in part also to challenge others to show
some benchmarking. I'd like to hear from others how stabs and DWARF
debug sizes compare for $YOUR_FAVORITE_APPLICATION...

Here's some more numbers, this time for gzip-1.5 on
powerpc64-unknown-linux-gnu, compiled with RedHat GCC 4.6.3-2,
compiler options "-O2 -g...".

size of         flags used
debug info      for gzip build
202329          -O2 -gstabs
233109          -O2 -gdwarf-2
218257          -O2 -gdwarf-4
116035          -O2 -gdwarf-4 -fno-var-tracking
171211          -O2 -gdwarf-4 -fno-var-tracking-assignments

Size of debug info is the output of:
 size -A gzip \
   | egrep "\.debug|\.stab" \
   | awk 'BEGIN{sum=0}{sum=sum+$2}END{print sum}'

i.e. on the final executable.

Again, DWARF is nowhere near an order of magnitude larger than stabs
info, as reported by the OP.

Note, I'm not using dwz because I don't think it's a fair comparison
against non-compressed stabs until dwz is made part of the default
tool chain.

Ciao!
Steven