This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reduce Dwarf Debug Size

Lawrence Crowl wrote:

> A major contribution to object and executable size is DWARF debug
> information size.  A major contribution to debug information
> size is struct descriptions replicated in several object files.
> This patch adds an option to reduce the size of this information,
> which mainly benefits C++.

Thank you for working on this problem.

I've read through this thread, and I agree with several of the key points:

1. A repository-based approach (whether based on -frepo and collect2, or
otherwise) would be a good thing to have in GCC, but isn't practical for
all projects.  (I think it could be practical for many projects, though.
 The usual objection is that you don't always have all the objects at
link time, but that can be overcome in many cases by generating all
necessary debug information when using "ld -r" or "ar" to build an
intermediate step.  You don't necessarily then eliminate all
duplication, but you eliminate much of it.)

2. A variant of (1) which leaves information in the object files doesn't
work for all projects (you need the object files at debug time, not just
the final executable), but clearly works for some, as Apple has
demonstrated.  That would be nice too.

3. This new option also won't work for everything, but it does do
something useful some of the time, and I think the heuristics are

5. We shouldn't let perfect be the enemy of good.

6. We should control the number of knobs people can twist, and the
number of points to which they can be twisted, and we already have too
many knobs and too many twist-points.

7. Apple pie is good.  Pecan pie can be good too, but only if doesn't
have too many nuts, and, anyhow, fruit pies are better than nut pies.

Here's my opinion:

1. I think that the idea of this patch is good.  It's a good-enough
heuristic that I imagine it will help a lot of people a lot.

2. As Daniel says, I don't think we need the full generality of the
patch, and I don't think that level of generality is desirable, either
in the documentation or the implementation.  In fact, I'm not sure *any*
generality is necessary.  I rather think we should just go with the
equivalent of -gstruct=base.

3. Most unnecessary debug information could be removed *at link-time* by
putting debugging information in COMDAT groups.  That would not affect
.o file size, which is also important, but it would help some users.
Just as having an -frepo-like option for debugging would be useful, so
would having a Borland-template model for debugging information.

4. As Mike says, this is a lot like #pragma interface/implementation,
further emphasizing the similarity between the debugging issue and the
template instantiation issue.  In fact, I believe that #pragma interface
already does suppress debug information.  (That's what the documentation
suggests, and if it doesn't so suppress, that's a bug, IMO.)  Can we
have a -f<something> option that says that we should assume pragma
interface for .h files, and pragma implementation for .c/.cpp files?
Or, if we must, -f<something>={debug,functions,class} to say that the
implicit pragma applies to debugging information, function bodies, and
class data?  The advantage of this approach is that it would reuse
existing code, rather than adding an entirely distinct mechanism.

5. I wish I had some apple pie.  Or cherry.  I'm not in the mood for pecan.

Mark Mitchell
(650) 331-3385 x713

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]