This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Code Bloat g++
- To: Jeffrey A Law <law at cygnus dot com>
- Subject: Re: Code Bloat g++
- From: Zack Weinberg <zack at wolery dot cumb dot org>
- Date: Sat, 19 Feb 2000 11:17:52 -0800
- 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
- References: <20000217115304.B13219@wolery.cumb.org> <1766.950821188@upchuck>
On Thu, Feb 17, 2000 at 01:59:48PM -0700, Jeffrey A Law wrote:
> In message <20000217115304.B13219@wolery.cumb.org>you write:
> > On Thu, Feb 17, 2000 at 08:39:58PM +0100, Martin v. Loewis wrote:
> > > 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.
Is that something the assembler should be doing, or the linker? Not
that I particularly want to go dig around in binutils, but...
zw