From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1424 invoked by alias); 15 Jan 2013 23:27:44 -0000 Received: (qmail 1394 invoked by uid 22791); 15 Jan 2013 23:27:43 -0000 X-SWARE-Spam-Status: No, hits=-5.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_DW,TW_GD X-Spam-Check-By: sourceware.org Received: from mail-vb0-f41.google.com (HELO mail-vb0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Jan 2013 23:27:08 +0000 Received: by mail-vb0-f41.google.com with SMTP id l22so743716vbn.28 for ; Tue, 15 Jan 2013 15:27:07 -0800 (PST) Received: by 10.52.88.33 with SMTP id bd1mr92657330vdb.70.1358292426866; Tue, 15 Jan 2013 15:27:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.215.38 with HTTP; Tue, 15 Jan 2013 15:26:26 -0800 (PST) In-Reply-To: <20130115175301.GA22635@host2.jankratochvil.net> References: <20130115175301.GA22635@host2.jankratochvil.net> From: Steven Bosscher Date: Tue, 15 Jan 2013 23:27:00 -0000 Message-ID: Subject: Re: stabs/dwarf size comparison on CSiBE (Was: stabs support in binutils, gcc, and gdb) To: Jan Kratochvil Cc: binutils@sourceware.org, Andreas Schwab , David Taylor , Doug Evans , nick clifton , gcc@gcc.gnu.org, gdb Content-Type: text/plain; charset=ISO-8859-1 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00066.txt.bz2 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