Re: stabs support in binutils, gcc, and gdb

[Cary Coutant <ccoutant@google.com>]

>> 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.
>
> The 3.4 number is the number I was interested in.
> Thanks for computing it.

It's not really fair to compare compressed DWARF with uncompressed stabs, is it?

> There are other things that can reduce the amount of dwarf, but the
> size reduction can depend on the app of course.
> I'm thinking of dwz and .debug_types.
> I wonder what 3.4 changes to with those applied.

David already said that dwz didn't help much, so that implies that
.debug_types won't help much either -- dwz should have removed any
duplicate type information that .debug_types would have removed.

I'm not going to argue that a ratio of 11.5 isn't kind of embarrassing
for DWARF, but I'd like to point out that you're not making an
apples-to-apples comparison. DWARF expresses a lot more about what's
going on in your program than stabs does, and it's reasonable to
expect it to be larger as a result. I compiled a very small C++ source
file with nothing more than a simple class definition and a main that
instantiates an instance of the class. Compiled with stabs, the .o
file is 3552 bytes with 1843 bytes of stabs info. Compiled with
DWARF-4, the .o file is 3576 bytes with 668 bytes of DWARF. For this
file, the two formats are encoding roughly the same information, and
DWARF is actually more efficient.

Next, I compiled a 5000-line C++ source file at both -O0 and -O2.
Here's the comparison at -O0:

stabs:   2,179,240 total           562,931 debug
dwarf:   4,624,816 total (2.1x)  1,965,448 debug (3.5x)

And at -O2:

stabs:   1,249,552 total           511,957 debug
dwarf:   4,612,240 total (3.7x)  2,281,564 debug (4.5x)

In general, DWARF is describing more about where variables live as
they move around during program execution. There's been lots of recent
work improving GCC's support for debugging optimized code, and that's
expensive to describe. Notice that when we turn on -O2, we get a lot
more DWARF information, while the stabs info is actually a bit smaller
(probably because -O2 generates less code). Even at -O0, DWARF is
describing more than stabs is.

I didn't see anything close to the 11.5 ratio that David got, so I'm
not sure what's so exceptional about your case. I'd be happy to take a
look if you can get me the files somehow.

We're working hard at improving the efficiency of DWARF -- there's a
lot of places where it can be improved, but I doubt the ratio between
stabs and DWARF will ever be much lower than ~3x, simply because
there's so much more information contained in the DWARF.

That extra information leads to a better debugging experience, but
it's a tradeoff. If stabs gives you a good-enough experience and the
size of DWARF is unbearable for you, then there's no reason to switch.

-cary