Re: Reduce Dwarf Debug Size

["Devang Patel" <devang dot patel at gmail dot com>]

>  - Have a symbol database per "project".

ok. Actually "per build target" makes more sense.

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

I used PCH's header validation scheme to handle different #define
settings. This approach is crude and overkill here but it works and
reuses existing implementation.
>  - 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.

one debug.o per header ? Very large portion of debug info is
type descriptions (from header files) that is duplicated in
all .o files

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

I got Xcode to this job :). This approach helped us move forward
and overcome "linker runs of vm memory" hurdle when darwin
tool chain used STABS (instead of DWARF).

-
Devang