Re: Reduce Dwarf Debug Size

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Feb 28, 2007 at 01:14:01PM -0800, Ian Lance Taylor wrote:
> Mike Stump <mrs@apple.com> writes:
> > I don't think this is probably the right direction to venture out in...
> > 
> > I have a counter proposal, instead, use -frepo to select where you
> > want to lay down the debug information.
> 
> -frepo is fragile for large projects, and it affects much more than
> debug information.  I don't think it is a real alternative.  It may
> well work for some people.  But I don't think the existence of -frepo
> is in itself a reason to not apply Lawrence's patch.

I'm afraid I agree with both of you... whatever that means.

I don't think the patch is a good direction.  The basic model of
-frepo makes more sense, though the actual implementation of collect2
doesn't seem like a good fit.  Didn't Apple work on a 'symbol
database' concept at one point?

My overall mental model for this problem, which I've spent quite a
long time thinking about but very little time fixing, goes like this:

  - Have a symbol database per "project".

  - When compiling a file, generate complete debug info for each
    included header iff the database says it is not yet output,
    or if (magic happens) it appears to be stale.  (other magic
    happens) to handle including files with different #define's
    that would affect the debug info.  Note, incompatible with
    omitting unused information.  We generate bigger debug info
    this way but a lot less overall.

  - Generate that debug info either into objects, or into the
    symbol database, which is more complicated but more flexible if
    multiple binaries get linked from the same object files.  In
    practice maybe that means one debug file per .o file.

  - At link time (other magic happens) the right object files get sent
    along to ld, this bit is familiar from collect2.

I realize a lot of work went into this patch, and I do appreciate
Lawrence working on this hard problem; but I think yet another (our
third or maybe fourth) option to omit a specific set of debug info is
the exactly wrong solution.

-- 
Daniel Jacobowitz
CodeSourcery