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

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


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