Re: Reduce Dwarf Debug Size

[Ian Lance Taylor <iant at google dot com>]

Daniel Jacobowitz <drow@false.org> writes:

> 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.

I don't agree.

I'm all in favor of some sort of symbol database.  But there are many
situations where that is simply not going to work.  People are not
used to having on-the-side data storage for their builds, and it would
not be a simple or trivial change for them.

I see Lawrence's patch as a different approach which will be useful
for different people.  Lawrence's patch is a much smaller and simpler
change than a symbol database.  It requires no significant change to
existing build systems.

I'm of course not saying that we have to accept Lawrence's patch.  But
I think that rejecting it in favor of an unbuilt system does not make
sense.  We should evaluate Lawrence's patch on its own merits: is it
useful, does it work, is it well-written.

Ian