Re: macros, debug information, and parse_macro_definition

[David Taylor <dtaylor@emc.com>]

> Date: Tue, 29 Apr 2003 10:55:58 -0400
> From: Andrew Cagney <ac131313@redhat.com>

> Have you thought about link time information compression?  One of the 
> complaints leveled at the macro stuff is the size of the resultant debug 
> info.
> 
> Andrew

I've thought some about (link time) debug information compression;
but, probably not as much as I should have.

[We already do some compression of STABS w/o macro information because
it's too voluminous as it is.  (And DWARF is worse still.)  I imagine
I will have to solve the problem in-house when macro information is
'turned on', so yes, this is a problem I need to think about.]

Since it's not in a separate section, you can't just say "oh, these
are identical, only keep one copy".

And you certainly (or, I certainly) don't want to tech LD about the
internals of STABS (or any debug format, for that matter) -- to, for
example, compare chunks that are bracketed by N_BINCL / N_EINCL (begin
include, end include), never mind more serious knowledge.

The choices that come immediately to mind are:

. teach LD about the internals of the debug format -- major blech.

. leave the information in the object files and have the executable
  file just 'reference' the object file information in some manner.

  [Sun does/did this with their compilers.  And this has some appeal.
  I believe that it would satisfy needs during development; but, I
  believe that it would not satisfy support needs.  So, I don't see us
  implementing it unless it turns out that its just a step along the
  way to the real solution.]

. have a separate program do some post processing of the debug symbols
  to compress them.

  [Hmmm, what would it take to get GNU LD to support piping its output
  to a program?  That way, the huge executable need never be stored on
  disk.  And then, if you invoked it via the specs file, it could be
  made pretty transparent to the user...  Just thinking out loud, mind
  you.]

. somehow generate only one copy in the first place.  Possibly by
  doing something with 'pre-compiled' header files?  What exactly, is
  unclear.

I believe that all of the above would require GDB work to support
them.