Re: stabs/dwarf size comparison on CSiBE (Was: stabs support in binutils, gcc, and gdb)
On Tue, Jan 15, 2013 at 6:53 PM, Jan Kratochvil wrote:
> On Tue, 15 Jan 2013 11:09:46 +0100, Steven Bosscher wrote:
>> Unless someone can shoot holes in this test approach,
>
> While the sum of *.o files sizes may make sense in some cases I would find
> more useful to measure it only for the final executables and after they have
> been processed by dwz.
>
> Besides dwz also .debug_* sections relocations have large size and all these
> relocations get removed in the final executable.
I know, but that's not how CSiBE is set up. My numbers bias against
DWARF for the reasons you mention, and the size of the DWARF info
*still* is not nearly an order of magnitude greater than stabs info.
I've posted these numbers in part also to challenge others to show
some benchmarking. I'd like to hear from others how stabs and DWARF
debug sizes compare for $YOUR_FAVORITE_APPLICATION...
Here's some more numbers, this time for gzip-1.5 on
powerpc64-unknown-linux-gnu, compiled with RedHat GCC 4.6.3-2,
compiler options "-O2 -g...".
size of flags used
debug info for gzip build
202329 -O2 -gstabs
233109 -O2 -gdwarf-2
218257 -O2 -gdwarf-4
116035 -O2 -gdwarf-4 -fno-var-tracking
171211 -O2 -gdwarf-4 -fno-var-tracking-assignments
Size of debug info is the output of:
size -A gzip \
| egrep "\.debug|\.stab" \
| awk 'BEGIN{sum=0}{sum=sum+$2}END{print sum}'
i.e. on the final executable.
Again, DWARF is nowhere near an order of magnitude larger than stabs
info, as reported by the OP.
Note, I'm not using dwz because I don't think it's a fair comparison
against non-compressed stabs until dwz is made part of the default
tool chain.
Ciao!
Steven
Re: stabs/dwarf size comparison on CSiBE (Was: stabs support in binutils, gcc, and gdb)
On Tue, 15 Jan 2013 11:09:46 +0100, Steven Bosscher wrote: > Unless someone can shoot holes in this test approach, While the sum of *.o files sizes may make sense in some cases I would find more useful to measure it only for the final executables and after they have been processed by dwz. Besides dwz also .debug_* sections relocations have large size and all these relocations get removed in the final executable. Thanks, Jan
stabs/dwarf size comparison on CSiBE (Was: stabs support in binutils, gcc, and gdb)
Hello, In this stabs vs. dwarf discussion, so far it's more been about assumptions than numbers. So let's throw in some numbers! The following debug sizes are for CSiBE-v2.1.1 on mipsisa64-elf, with the LRA branch at r195108. All CSiBE test cases are packages written in C. Debug size is computed as the total size of all ".stabs*" or ".debug*" sections as computed by "size -A" (sysv style size output) on individual object files (so before linking) and summed up by awk (*). Tested debug formats are "none", "stabs", "dwarf2", and "dwarf4". Compiler options were "-Os" for all four tested debug formats. Debug info was output with "-gstabs", "-gdwarf-2", and "-gdwarf-4". And the results are: package stabs dwarf2 dwarf4 bzip2-1.0.2 372772 289386 279670 cg_compiler... 1355948 1381734 1314676 compiler152178 156644 148458 flex-2.5.31 665588 511856 488256 jikespg-1.3 944126 773358 749050 jpeg-6b 3285854 2186640 2110290 libmspack 602692 421792 407070 libpng-1.2.51064722 1017116 975098 linux-2.4.23... 536172304092124638353402 lwip-0.5.3... 576260 402830 381902 mpeg2dec-0.3.1 492918 336912 327072 mpgcut-1.1 46956 51854 49490 OpenTCP-1.0.4 873008 223646 212822 replaypc-0.4... 1009322 445296 424136 teem-1.6.0-src 133744367259308 6954802 ttt-0.10.1... 208516 113828 109776 unrarlib-0.4.0 91236 79396 75256 zlib-1.1.4 280272 201392 193506 TOTAL 790140345677423453554732 DEBUG/TEXT 16.49 11.85 11.18 (*) the test script actually takes the sum of sizes for all ".text*", ".stabs*", and ".debug*" sections, and the ".text*" size is subtracted to get the debug info sizes. Unless someone can shoot holes in this test approach, the results suggest that DWARF debug size is *smaller* than stabs, at least for mipsisa64. Ciao! Steven
Re: stabs support in binutils, gcc, and gdb
> 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
Re: stabs support in binutils, gcc, and gdb
David Taylor 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, sch...@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
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
>> 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
Andreas Schwab wrote:
> David Taylor 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
On Fri, Jan 11, 2013 at 6:55 PM, Cary Coutant 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
On Fri, Jan 11, 2013 at 7:17 PM, Ian Lance Taylor wrote: > On Fri, Jan 11, 2013 at 5:55 PM, Cary Coutant 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
David Taylor 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, sch...@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
On Fri, Jan 11, 2013 at 5:55 PM, Cary Coutant 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
>> 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
On Fri, Jan 11, 2013 at 6:52 AM, David Taylor wrote: > Doug Evans 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
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 0208deb8 2**2
CONTENTS, READONLY, DEBUGGING
78 .stabstr 00e0b6bc 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
> 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.
Re: stabs support in binutils, gcc, and gdb
On Tue, Jan 8, 2013 at 9:46 AM, Arnaud Charlet 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
> 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
On Tue, Jan 8, 2013 at 3:10 AM, Joel Brobecker 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
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
> 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
On Sat, Jan 5, 2013 at 9:52 AM, Joel Brobecker 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
> 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
On Sat, Jan 5, 2013 at 2:53 AM, Joel Brobecker 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
> > 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
On Fri, Jan 4, 2013 at 3:20 PM, David Edelsohn wrote: > On Thu, Jan 3, 2013 at 11:12 PM, Joel Brobecker 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
On Thu, Jan 3, 2013 at 11:12 PM, Joel Brobecker 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
> 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
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.
Re: stabs support in binutils, gcc, and gdb
On Thu, Jan 3, 2013 at 4:53 PM, Jonas Maebe 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
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
On Thu, Jan 3, 2013 at 12:02 PM, Tom Tromey wrote: >> "David" == David Taylor 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
> "David" == David Taylor 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
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
> 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
On Thu, Jan 3, 2013 at 5:21 PM, David Taylor 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
stabs support in binutils, gcc, and gdb
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
