From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18934 invoked by alias); 11 Jan 2013 14:53:55 -0000 Received: (qmail 18912 invoked by uid 22791); 11 Jan 2013 14:53:54 -0000 X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,TW_BJ,TW_DW,TW_GD,TW_JC X-Spam-Check-By: sourceware.org Received: from hop-nat-141.emc.com (HELO mexforward.lss.emc.com) (168.159.213.141) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 Jan 2013 14:53:47 +0000 Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0BErILS014994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jan 2013 09:53:23 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 11 Jan 2013 09:53:00 -0500 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0BEr0VP031456; Fri, 11 Jan 2013 09:53:00 -0500 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id 95A205A8751; Fri, 11 Jan 2013 09:52:58 -0500 (EST) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id 925315A86D3; Fri, 11 Jan 2013 09:52:58 -0500 (EST) To: Doug Evans cc: nick clifton , binutils@sourceware.org, gcc@gcc.gnu.org, gdb Subject: Re: stabs support in binutils, gcc, and gdb In-reply-to: References: <12972.1357230104@usendtaylorx2l> <50E5B73C.8090009@redhat.com> Comments: In-reply-to Doug Evans message dated "Thu, 03 Jan 2013 20:30:52 -0700." Date: Fri, 11 Jan 2013 14:53:00 -0000 Message-ID: <13440.1357915978@usendtaylorx2l> From: David Taylor X-EMM-MHVC: 1 X-IsSubscribed: yes 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/msg00040.txt.bz2 Doug Evans wrote: > On Thu, Jan 3, 2013 at 9:52 AM, nick clifton wrote: > >> Switching to DWARF causes our build products directory (which contains > >> *NONE* of the intermediate files) to swell from 1.2 GB to 11.5 GB. > >> Ouch! The DWARF ELF files are 8-12 times the size of the STABS ELF > >> files. > >> > >> If the DWARF files were, say, a factor of 2 the size of the STABS files, > >> I could probably sell people on switching to DWARF; but, a factor of 8 > >> to 12 is too much. > > > > > > Have you tried using a DWARF compression tool like dwz ? > > > > http://gcc.gnu.org/ml/gcc/2012-04/msg00686.html > > > > Or maybe the --compress-debug-sections option to objcopy ? > > Yeah, that would be really useful data to have. > > Plus, there's also -gdwarf-4 -fdebug-types-section. > > So while plain dwarf may be 8-12x of stabs, progress has been made, > and we shouldn't base decisions on incomplete analyses. > > If we had data to refute (or substantiate) claims that dwarf was > *still* X% larger than stabs and people were still avoiding dwarf > because of it, that would be really useful. > DWARF alone is more than 8-12 times larger than STABS alone. For our product, the DWARF elf file is 8-12 times larger than the STABS elf file. But, part of the file is the text + data + symbol table + various elf headers. So, the debugging information swelled by a larger factor. Some numbers. Picking d90a.elf because it is first alphabetically. {As to what d90f.elf is -- that's unimportant; but, it's the kernel for one of the boards in one of our hardware products.] With STABS, it's 83,945,437 bytes. If I strip it, it's 34,411,472 bytes. SIZE reports that the text is 26,073,758 bytes and that the data is 8,259,394 bytes, for a total of 34,333,152. So, the stipped size is 78,320 bytes larger than text+data. >From objdump: 77 .stab 01f40700 0000000000000000 0000000000000000 0208deb8 2**2 CONTENTS, READONLY, DEBUGGING 78 .stabstr 00e0b6bc 0000000000000000 0000000000000000 03fce5b8 2**0 CONTENTS, READONLY, DEBUGGING So, the two STABS sections come to a total of 47,496,636 bytes. (Stripped size 34,411,472) + (size of .stab & .stabstr) is 2,037,329 bytes shy of the unstriped size. Presumably symbols. DWARF 4 total file size 967,579,501 bytes. Ouch! Stripped 34,411,440 bytes. Which is 32 bytes smaller than the stabs case. Continuing... Adding up the various debugging sections I get 931,076,638 bytes for the .debug* sections 52,977 for the .stab and .stabstr sections (not sure where they came from -- maybe libgcc? Origin is unimportant for the present purposes.) Ignoring the 52,977 stabs stuff, that's 931076638 / 47496636 ~= 19.6. Using DWZ reduced the elf file size by approximately 1% when using dwarf 3 or dwarf 4. With dwarf 2 the file is about 10% bigger and dwz reduces it by about 10% -- i.e., to about the same file size as when using dwarf [34]. Using objcopy --compress-debug-sections reduced the overall elf file size to approximately 3.4 times that of the stabs file -- definitely better than the 11.5 ratio when not using it. Summarizing: STABS: total file size: 83,945,437 text+data: 34,333,152 debugging: 47,496,636 other: 2,115,649 DWARF: total file size: 967,579,501 text+data: 34,333,120 (don't know why it is 32 bytes smaller) DWARF debugging: 931,076,638 STABS debugging: 52,977 other: 2,116,766 file size ratio: 967,579,501 / 83,945,437 = 11.5 debug size ratio: 931,076,638 / 47,496,636 = 19.6 (It would actually be slightly worse if the remaining ~50K of STABS was converted to DWARF.) If I use objcopy --compress-debug-sections to compress the DWARF debug info (but don't use it on the STABS debug info), then the file size ratio is 3.4. While 3.4 is certainly better than 11.5, unless I can come up with a solution where the ratio is less than 2, I'm not currently planning on trying to convince them to switch to DWARF. David