Re: stabs support in binutils, gcc, and gdb

Re: stabs support in binutils, gcc, and gdb

[Tom Tromey]

>>>>> "David" == David Taylor <dtaylor@emc.com> writes:

David> It appears that STABS is largely in maintenance mode.  Are there any
David> plans to deprecate STABS support?  If STABS enhancements were made and
David> posted would they be frowned upon?  Or would they be reviewed for
David> possible inclusion in a future release?

In gdb things are rarely pre-emptively deprecated like this.
If someone wants to maintain the stabs code, then it will stay alive.
The most important thing is having a reasonably responsive maintainer --
it is the un-maintained code that tends to slowly rot and then
eventually be deleted.

Tom

Re: stabs support in binutils, gcc, and gdb

[David Edelsohn]

On Thu, Jan 3, 2013 at 12:02 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "David" == David Taylor <dtaylor@emc.com> writes:
>
> David> It appears that STABS is largely in maintenance mode.  Are there any
> David> plans to deprecate STABS support?  If STABS enhancements were made and
> David> posted would they be frowned upon?  Or would they be reviewed for
> David> possible inclusion in a future release?
>
> In gdb things are rarely pre-emptively deprecated like this.
> If someone wants to maintain the stabs code, then it will stay alive.
> The most important thing is having a reasonably responsive maintainer --
> it is the un-maintained code that tends to slowly rot and then
> eventually be deleted.

AIX still uses STABS.  GCC produces it and GDB consumes it.

Recent releases of AIX now support DWARF as well, but GCC and GDB have
not been converted to use it on AIX.

- David

Re: stabs support in binutils, gcc, and gdb

[Jonas Maebe]

On 03 Jan 2013, at 21:53, David Edelsohn wrote:

> AIX still uses STABS.  GCC produces it and GDB consumes it.

More precisely, AIX uses Stabx. It's similar to Stabs, but different in quite a few ways. To add to the confusion, GCC produces and GDB consumes a hybrid of Stabs and Stabx on AIX for some reason (xlc and the native dbx produce/consume pure Stabx, which is not understood by GDB; conversely, dbx does not understand the GCC/GDB Stabx-Stabs hybrid).


Jonas

Re: stabs support in binutils, gcc, and gdb

[David Edelsohn]

On Thu, Jan 3, 2013 at 4:53 PM, Jonas Maebe <jonas.maebe@elis.ugent.be> wrote:
>
> On 03 Jan 2013, at 21:53, David Edelsohn wrote:
>
>> AIX still uses STABS.  GCC produces it and GDB consumes it.
>
> More precisely, AIX uses Stabx. It's similar to Stabs, but different in quite a few ways. To add to the confusion, GCC produces and GDB consumes a hybrid of Stabs and Stabx on AIX for some reason (xlc and the native dbx produce/consume pure Stabx, which is not understood by GDB; conversely, dbx does not understand the GCC/GDB Stabx-Stabs hybrid).

That description is not entirely correct.

GDB understands XLC stabs debugging information and GCC can be
instructed to emit the subset of stabs information that AIX dbx can
consume.

- David

Re: stabs support in binutils, gcc, and gdb

[Joel Brobecker]

> AIX still uses STABS.  GCC produces it and GDB consumes it.
> 
> Recent releases of AIX now support DWARF as well, but GCC and GDB have
> not been converted to use it on AIX.

Note that GNU ld is now completely usable; and one of the side
effects of using GNU ld is the ability to switch over to DWARF,
even on older versions such as AIX 5.1.

-- 
Joel

Re: stabs support in binutils, gcc, and gdb

[David Edelsohn]

On Thu, Jan 3, 2013 at 11:12 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> AIX still uses STABS.  GCC produces it and GDB consumes it.
>>
>> Recent releases of AIX now support DWARF as well, but GCC and GDB have
>> not been converted to use it on AIX.
>
> Note that GNU ld is now completely usable; and one of the side
> effects of using GNU ld is the ability to switch over to DWARF,
> even on older versions such as AIX 5.1.

Can you please clarify what "GNU ld is not completely usable" means?
Is that referring to DWARF support? to compatibility with specific AIX
releases? to compatibility with AIX DWARF feature?

Thanks, David

Re: stabs support in binutils, gcc, and gdb

[David Edelsohn]

On Fri, Jan 4, 2013 at 3:20 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Thu, Jan 3, 2013 at 11:12 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>>> AIX still uses STABS.  GCC produces it and GDB consumes it.
>>>
>>> Recent releases of AIX now support DWARF as well, but GCC and GDB have
>>> not been converted to use it on AIX.
>>
>> Note that GNU ld is now completely usable; and one of the side
>> effects of using GNU ld is the ability to switch over to DWARF,
>> even on older versions such as AIX 5.1.
>
> Can you please clarify what "GNU ld is not completely usable" means?
> Is that referring to DWARF support? to compatibility with specific AIX
> releases? to compatibility with AIX DWARF feature?

Sorry, I meant what "GNU ld is now completely usable" means because I
believe that it actually is NOT completely usable on AIX.

Thanks, David

Re: stabs support in binutils, gcc, and gdb

[Joel Brobecker]

> > Can you please clarify what "GNU ld is not completely usable" means?
> > Is that referring to DWARF support? to compatibility with specific AIX
> > releases? to compatibility with AIX DWARF feature?
> 
> Sorry, I meant what "GNU ld is now completely usable" means because I
> believe that it actually is NOT completely usable on AIX.

AdaCore has successfully switched to GNU ld on AIX, tested on AIX
version 5.x and 7.x. We use a version derived from an old HEAD,
I believe, but the latest release might have all the necessary
changes. I cannot tell you that it's perfect, and some options
provided by the native linker might not be implemented (particularly
the options relating to TOCs). But we released GNAT Pro 7.0.1/7.0.2
using GNU ld early last year, and I don't remember seeing any real
problem being reported.

We had to do some changes, and make some fixes, mostly done by
Tristan, and normally they should have been contributed to the
FSF tree. Overall, I think we're pretty happy with GNU ld as
of now.

-- 
Joel

Re: stabs support in binutils, gcc, and gdb

[David Edelsohn]

On Sat, Jan 5, 2013 at 2:53 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> > Can you please clarify what "GNU ld is not completely usable" means?
>> > Is that referring to DWARF support? to compatibility with specific AIX
>> > releases? to compatibility with AIX DWARF feature?
>>
>> Sorry, I meant what "GNU ld is now completely usable" means because I
>> believe that it actually is NOT completely usable on AIX.
>
> AdaCore has successfully switched to GNU ld on AIX, tested on AIX
> version 5.x and 7.x. We use a version derived from an old HEAD,
> I believe, but the latest release might have all the necessary
> changes. I cannot tell you that it's perfect, and some options
> provided by the native linker might not be implemented (particularly
> the options relating to TOCs). But we released GNAT Pro 7.0.1/7.0.2
> using GNU ld early last year, and I don't remember seeing any real
> problem being reported.
>
> We had to do some changes, and make some fixes, mostly done by
> Tristan, and normally they should have been contributed to the
> FSF tree. Overall, I think we're pretty happy with GNU ld as
> of now.

It does not look like the changes were merged into the FSF tree.  This
also does not support some of the more recent AIX features added to
GCC.

I also infer that Adacore continues to use the AIX assembler, not GNU as.

Thanks, David

Re: stabs support in binutils, gcc, and gdb

[Joel Brobecker]

> It does not look like the changes were merged into the FSF tree.  This
> also does not support some of the more recent AIX features added to
> GCC.

Tristan is usually pretty good at sending these sorts of patches.
I will ask him on Monday if some might be missing. He's been
extremely busy lately, so it's a possibility. It would also be
useful to explain how you are basing your evaluation, and in
particular say what does not work for you.

> I also infer that Adacore continues to use the AIX assembler, not GNU as.

We also use GNU as.

-- 
Joel

Re: stabs support in binutils, gcc, and gdb

[David Edelsohn]

On Sat, Jan 5, 2013 at 9:52 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> It does not look like the changes were merged into the FSF tree.  This
>> also does not support some of the more recent AIX features added to
>> GCC.
>
> Tristan is usually pretty good at sending these sorts of patches.
> I will ask him on Monday if some might be missing. He's been
> extremely busy lately, so it's a possibility. It would also be
> useful to explain how you are basing your evaluation, and in
> particular say what does not work for you.

I and others have not been able to use GNU as and GNU ld to bootstrap
GCC. The resulting object files and shared objects mostly worked in
small experiments, but failed for larger projects, like GCC.

Also, GNU as and GNU ld do not contain support for the new
cmodel=large and thread local storage support added to GCC.

- David

Re: stabs support in binutils, gcc, and gdb

[Joel Brobecker]

> I and others have not been able to use GNU as and GNU ld to bootstrap
> GCC. The resulting object files and shared objects mostly worked in
> small experiments, but failed for larger projects, like GCC.
> 
> Also, GNU as and GNU ld do not contain support for the new
> cmodel=large and thread local storage support added to GCC.

Perfect, this gives me a better idea of what to ask for on Monday.
I will see what the current status is. We do boostrap GCC, but
I don't think we've tried with the current HEAD, only GCC 4.7.

-- 
Joel

Re: stabs support in binutils, gcc, and gdb

[Joel Brobecker]

I was able to speak to Tristan, yesterday, and he confirmed that
we haven't been able to contribute a few of the patches he wrote.
Unfortunately, his TODO list is more than full, at the moment, and
we don't think he'll have time to work on that for a while. I might
have time in the next few weeks to track them down - if I do, I will
post them.

With all patches, we are able to bootstrap GCC 4.7. But we haven't
tried the HEAD version. From David's report, it sounds like we should
expect additional work if we want to do it.

-- 
Joel

Re: stabs support in binutils, gcc, and gdb

[David Edelsohn]

On Tue, Jan 8, 2013 at 3:10 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> I was able to speak to Tristan, yesterday, and he confirmed that
> we haven't been able to contribute a few of the patches he wrote.
> Unfortunately, his TODO list is more than full, at the moment, and
> we don't think he'll have time to work on that for a while. I might
> have time in the next few weeks to track them down - if I do, I will
> post them.
>
> With all patches, we are able to bootstrap GCC 4.7. But we haven't
> tried the HEAD version. From David's report, it sounds like we should
> expect additional work if we want to do it.

It would be helpful for Adacore to contribute the support upstream
into the FSF tree, not only to make GNU Binutils more useful on AIX
but to avoid others duplicating your work -- especially in
incompatible ways.

The large TOC feature (cmodel=large) is not used by default and the
TLS feature is not enabled by default, so HEAD probably should
bootstrap with your private changes to Binutils. TLS tests for
assembler support, so that should fail with Binutils.

I had wanted your feedback about TLS within Ada before enabling the
configuration test by default, but that apparently will not be
possible with the way that Adacore's development model on AIX has
diverged.

Thanks, David

Re: stabs support in binutils, gcc, and gdb

[Arnaud Charlet]

> It would be helpful for Adacore to contribute the support upstream
> into the FSF tree, not only to make GNU Binutils more useful on AIX
> but to avoid others duplicating your work -- especially in
> incompatible ways.

Indeed.

> The large TOC feature (cmodel=large) is not used by default and the
> TLS feature is not enabled by default, so HEAD probably should
> bootstrap with your private changes to Binutils. TLS tests for
> assembler support, so that should fail with Binutils.
> 
> I had wanted your feedback about TLS within Ada before enabling the
> configuration test by default, but that apparently will not be
> possible with the way that Adacore's development model on AIX has
> diverged.

We haven't done any work to support TLS in gnu as/ld on AIX (other
than ignore these sections for now to avoid generating hard errors), so
enabling TLS in GCC would indeed cause some troubles, although we don't
use TLS directly in GNAT.

Arno

Re: stabs support in binutils, gcc, and gdb

[David Edelsohn]

On Tue, Jan 8, 2013 at 9:46 AM, Arnaud Charlet <charlet@adacore.com> wrote:

> We haven't done any work to support TLS in gnu as/ld on AIX (other
> than ignore these sections for now to avoid generating hard errors), so
> enabling TLS in GCC would indeed cause some troubles, although we don't
> use TLS directly in GNAT.

Okay.  If there is no direct use of TLS in GNAT, then testing with the
new support would not provide any additional feedback and sanity
checks of the support.

Thanks, David

Re: stabs support in binutils, gcc, and gdb

[Arnaud Charlet]

> Okay.  If there is no direct use of TLS in GNAT, then testing with the
> new support would not provide any additional feedback and sanity
> checks of the support.

Right.

stabs support in binutils, gcc, and gdb

[David Taylor]

What is the status of STABS support?

I know that there is considerably more activity around DWARF than STABS.
It appears that STABS is largely in maintenance mode.  Are there any
plans to deprecate STABS support?  If STABS enhancements were made and
posted would they be frowned upon?  Or would they be reviewed for
possible inclusion in a future release?

[We have copyright assignments in place for past and future changes to
BINUTILS, GCC, and GDB -- and it took almost 4 years from start to
finish -- I do not want to ever have to go through that again with the
company lawyers!  So, paperwork should not be an issue.]

I know that DWARF is more expressive than STABS.  And if it didn't cause
such an explosion in disk space usage, we would probably have switched
from STABS to DWARF years ago.

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.

Thanks.

David

Re: stabs support in binutils, gcc, and gdb

[Richard Biener]

On Thu, Jan 3, 2013 at 5:21 PM, David Taylor <dtaylor@emc.com> wrote:
> What is the status of STABS support?
>
> I know that there is considerably more activity around DWARF than STABS.
> It appears that STABS is largely in maintenance mode.  Are there any
> plans to deprecate STABS support?  If STABS enhancements were made and
> posted would they be frowned upon?  Or would they be reviewed for
> possible inclusion in a future release?
>
> [We have copyright assignments in place for past and future changes to
> BINUTILS, GCC, and GDB -- and it took almost 4 years from start to
> finish -- I do not want to ever have to go through that again with the
> company lawyers!  So, paperwork should not be an issue.]
>
> I know that DWARF is more expressive than STABS.  And if it didn't cause
> such an explosion in disk space usage, we would probably have switched
> from STABS to DWARF years ago.
>
> 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.

The idea was to have a working DWARF -> STABS translator, eventually
as part of binutils.

Richard.

> Thanks.
>
> David

Re: stabs support in binutils, gcc, and gdb

[Joel Brobecker]

> What is the status of STABS support?

In terms of GDB, it is no longer actively maintained. But if you
submit patches, I will do my best to review them.

-- 
Joel

Re: stabs support in binutils, gcc, and gdb

[nick clifton]

Hi David,

> What is the status of STABS support?

Essentially it is in maintenance mode.  But this is due to lack of 
developers interested in extending STABS support, rather than a policy 
of maintenance-only.


> Are there any plans to deprecate STABS support?

No, none.


> If STABS enhancements were made and
> posted would they be frowned upon?  Or would they be reviewed for
> possible inclusion in a future release?

No, they would be reviewed and, assuming that they are suitable, they 
would be accepted for inclusion in future releases.


> 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 ?

Cheers
   Nick

Re: stabs support in binutils, gcc, and gdb

[Doug Evans]

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.

Re: stabs support in binutils, gcc, and gdb

[David Taylor]

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

Re: stabs support in binutils, gcc, and gdb

[Doug Evans]

On Fri, Jan 11, 2013 at 6:52 AM, David Taylor <dtaylor@emc.com> wrote:
> Doug Evans <dje@google.com> wrote:
>> So while plain dwarf may be 8-12x of stabs, progress has been made,
>> and we shouldn't base decisions on incomplete analyses.
>
> ...
>
> 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.

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.

Re: stabs support in binutils, gcc, and gdb

[Cary Coutant]

>> 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

Re: stabs support in binutils, gcc, and gdb

[Ian Lance Taylor]

On Fri, Jan 11, 2013 at 5:55 PM, Cary Coutant <ccoutant@google.com> wrote:
>
> Next, I compiled a 5000-line C++ source file at both -O0 and -O2.

I have to assume that David is working with C code, as stabs debugging
for C++ is nearly unusable.

Ian

Re: stabs support in binutils, gcc, and gdb

[Doug Evans]

On Fri, Jan 11, 2013 at 7:17 PM, Ian Lance Taylor <iant@google.com> wrote:
> On Fri, Jan 11, 2013 at 5:55 PM, Cary Coutant <ccoutant@google.com> wrote:
>>
>> Next, I compiled a 5000-line C++ source file at both -O0 and -O2.
>
> I have to assume that David is working with C code, as stabs debugging
> for C++ is nearly unusable.

That was my assumption, fwiw.

Re: stabs support in binutils, gcc, and gdb

[Cary Coutant]

>> Next, I compiled a 5000-line C++ source file at both -O0 and -O2.
>
> I have to assume that David is working with C code, as stabs debugging
> for C++ is nearly unusable.

I assumed that too, but I figured C++ would be worse than C as far as
DWARF vs. stabs size. I'd still be interested to figure out what's
causing that 11.5x expansion.

-cary

Re: stabs support in binutils, gcc, and gdb

[Doug Evans]

On Fri, Jan 11, 2013 at 6:55 PM, Cary Coutant <ccoutant@google.com> wrote:
>>> 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?

Data is data.
Plus I doubt anyone is going to go to the trouble of compressing stabs.

Not that I think it's a priori worth the effort to dig deeper, but for
another datapoint, Redhat added an lza-compressed mini-dwarf-debug
section.  I'm not sure what it supports (if anything beyond making
backtraces better).

Re: stabs support in binutils, gcc, and gdb

[Jan Kratochvil]

On Mon, 14 Jan 2013 17:12:25 +0100, Doug Evans wrote:
> Not that I think it's a priori worth the effort to dig deeper, but for
> another datapoint, Redhat added an lza-compressed mini-dwarf-debug
> section.  I'm not sure what it supports (if anything beyond making
> backtraces better).

It can contain anything what separate debug info file may contain, incl.
.debug_* sections.  Access to those sections may be performance sub-optimal
(decompressing blocks per seek request), unaware if usably or unusably slow.


Jan

Re: stabs support in binutils, gcc, and gdb

[Andreas Schwab]

David Taylor <dtaylor@emc.com> writes:

> {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.]

Is it an optimized or an unoptimized build?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: stabs support in binutils, gcc, and gdb

[David Taylor]

Andreas Schwab <schwab@linux-m68k.org> wrote:

> David Taylor <dtaylor@emc.com> writes:
> 
> > {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.]
> 
> Is it an optimized or an unoptimized build?

Optimized, -O2.  According to find piped to wc, there's 2587 C files, 11
assembly files, 5 C++ files, and 2839 header files.

Across the files, there's 4.9M lines in C files, 870K lines in header
files, 9.7K lines in assembly, and 5.9K lines in C++.

Re: stabs support in binutils, gcc, and gdb

[Andreas Schwab]

David Taylor <dtaylor@emc.com> writes:

> Optimized, -O2.

Then it is expected that dwarf debug is much bigger than stabs debug,
since the latter does not include any of the value tracking capabilities
of dwarf.  Without that it is almost impossible for a debugger to
display the true value of local variables.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: stabs support in binutils, gcc, and gdb

[Eric Botcazou]

> Then it is expected that dwarf debug is much bigger than stabs debug,
> since the latter does not include any of the value tracking capabilities
> of dwarf.  Without that it is almost impossible for a debugger to
> display the true value of local variables.

Indeed.  And it would be interesting to have figures with
  (1) -fno-var-tracking-assignments
and
  (2) -fno-var-tracking
then.

-- 
Eric Botcazou