From: David Taylor <dtaylor@emc.com>
To: Doug Evans <dje@google.com>
Cc: nick clifton <nickc@redhat.com>,
binutils@sourceware.org, gcc@gcc.gnu.org,
gdb <gdb@sourceware.org>
Subject: Re: stabs support in binutils, gcc, and gdb
Date: Fri, 11 Jan 2013 14:53:00 -0000 [thread overview]
Message-ID: <13440.1357915978@usendtaylorx2l> (raw)
In-Reply-To: <CADPb22TeDa3M9tw94=7XuAdbcVem-sciy2qEgCr_N1CcPWoEzA@mail.gmail.com>
Doug Evans <dje@google.com> wrote:
> On Thu, Jan 3, 2013 at 9:52 AM, nick clifton <nickc@redhat.com> 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
next prev parent reply other threads:[~2013-01-11 14:53 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-03 16:22 David Taylor
2013-01-03 16:42 ` Richard Biener
2013-01-03 16:53 ` Joel Brobecker
2013-01-03 16:56 ` nick clifton
2013-01-04 3:31 ` Doug Evans
2013-01-11 14:53 ` David Taylor [this message]
2013-01-11 17:41 ` Doug Evans
2013-01-12 1:55 ` Cary Coutant
2013-01-12 2:17 ` Ian Lance Taylor
2013-01-14 16:06 ` Doug Evans
2013-01-14 19:45 ` Cary Coutant
2013-01-14 16:12 ` Doug Evans
2013-01-14 19:49 ` Jan Kratochvil
2013-01-12 13:26 ` Andreas Schwab
2013-01-14 18:57 ` David Taylor
2013-01-14 22:18 ` Andreas Schwab
2013-01-14 23:41 ` Eric Botcazou
[not found] <12972.1357230104__33958.3243280233$1357230256$gmane$org@usendtaylorx2l>
2013-01-03 17:02 ` Tom Tromey
2013-01-03 20:53 ` David Edelsohn
2013-01-03 21:53 ` Jonas Maebe
2013-01-03 22:02 ` David Edelsohn
2013-01-04 4:12 ` Joel Brobecker
2013-01-04 20:20 ` David Edelsohn
2013-01-05 0:11 ` David Edelsohn
2013-01-05 7:53 ` Joel Brobecker
2013-01-05 13:28 ` David Edelsohn
2013-01-05 14:52 ` Joel Brobecker
2013-01-06 0:26 ` David Edelsohn
2013-01-06 7:00 ` Joel Brobecker
2013-01-08 8:10 ` Joel Brobecker
2013-01-08 14:38 ` David Edelsohn
2013-01-08 14:46 ` Arnaud Charlet
2013-01-08 14:49 ` David Edelsohn
2013-01-08 14:58 ` Arnaud Charlet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13440.1357915978@usendtaylorx2l \
--to=dtaylor@emc.com \
--cc=binutils@sourceware.org \
--cc=dje@google.com \
--cc=gcc@gcc.gnu.org \
--cc=gdb@sourceware.org \
--cc=nickc@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox