This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Code Bloat g++
- To: Zack Weinberg <zack at wolery dot cumb dot org>
- Subject: Re: Code Bloat g++
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 17 Feb 2000 13:59:48 -0700
- cc: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>, jbuck at possibly dot synopsys dot com, pfeifer at dbai dot tuwien dot ac dot at, NEELAKANTH dot NADGIR at sun dot com, gcc at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <20000217115304.B13219@wolery.cumb.org>you write:
> On Thu, Feb 17, 2000 at 08:39:58PM +0100, Martin v. Loewis wrote:
> > > > > Anyway, as Alexandre points out: this is debugging information, so
> > > > > what is the problem?
> > >
> > > Argh! I am astounded at how many C++ compiler developers make such com
> ments.
> > > I am familiar with a commercial project that is at a crisis point becau
> se
> > > of the massive, massive size of debug information generated by a
> > > well-known proprietary C++ compiler (literally gigabytes of debug
> > > information for a single medium-to-large application, more than triple
> the
> > > size of the previous release). Please let's not make g++ suck just as
> > > badly.
> >
> > That assumes that large debug information is redundant to a ridiculous
> > degree. I don't know whether this is the case, but until I'm proven
> > wrong, I'd always assume that every single bit in the debug
> > information serves a purpose.
> >
> > With that assumption, it is ok for me if debug information is large -
> > because it could not be much smaller.
>
> Stabs is in fact quite redundant, because everything is stored as
> ASCII strings. I've seen the size cut in half by using -gdwarf-2
> instead.
Note that for stabs we have the ability to remove duplicate information
from the debugging sections. We do not have that capability for dwarf2
right now.
jeff