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