This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: stabs support in binutils, gcc, and gdb
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