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: Sat, 19 Feb 2000 13:03:36 -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 <20000219111752.C516@wolery.cumb.org>you write:
> 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 ridicul
> ous
> > > > 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...
It's mostly a linker issue, though the compiler & assembler usually have to
be modified to make this kind of thing work.
Jason has a couple proposals which make this kind of thing easier to do in
dwarf2, but I don't know their details.
jeff