Re: When to emit C++ debug info?

[Geoff Keating <geoffk at desire dot geoffk dot org>]

> From: Daniel Berlin <dberlin@dberlin.org>
> Date: Sat, 3 Jan 2004 21:56:57 -0500

> On Jan 3, 2004, at 8:36 PM, Geoff Keating wrote:
> 
> >> X-Original-To: geoffk@foam.wonderslug.com
> >> Date: Sat, 3 Jan 2004 19:05:42 -0600 (CST)
> >> From: Chris Lattner <sabre@nondot.org>
> >
> >> Geoff Keating writes:
> >>> I think we'll want to be able to do it these ways:
> >>> - One way where the minimal debugging information is emitted so that
> >>>   when put together, the whole program has complete debugging
> >>>   information; and
> >>> - Another way where complete information is emitted for a single 
> >>> file.
> >>>
> >>> I'm not sure why you'd want something between these two extremes.
> >>
> >> Why not always do #2, and have the linker eliminate the duplicate
> >> information?
> >
> > Because it makes .o files large, and that makes the linker slow
> > because it has to process the huge collection of .o files.
> 
> Okay, so keep a database of debug info for a given compilation, stored 
> in an aside file, and use that to make sure you don't output debug info 
> you've already outputted for other objects, to keep object file size 
> down.
> This should require no more or less of a make utility than PCH does.

A better design for this is Devang's "symbol separation" stuff.  It
does work, but it requires even more build system changes than PCH.
(You don't want a read-write database, because then you have to handle
locking, removing outdated entries from the database, and so on.)

> You can't possibly know what's going to be in the other files before 
> you see them, so a strategy " where the minimal debugging information 
> is emitted so that when put together, the whole program has complete 
> debugging information" just won't work well, unless you were planning 
> on implementing it by knowing what you've already emitted elsewhere.

You can do what you do for C++ vtable output, use the linkage rules to
determine a single place, or a few places, that debug information
might need to be output.

For instance, you could do it like this: A given piece of debugging
information need not be placed in a .o file if the lexicographically
first external symbol used by the .o file, whose debugging information
requires that piece of information, is not defined in the same .o
file.  That is, in

struct x { int y; };
extern int bar (struct x *);
int foo (void) {
  struct x tt = { 3 };
  return bar(&tt);
}

we decide that because 'bar' is alphabetically before 'foo',
everything to do with 'bar' will already be output in its .o file, so
we don't have to output any of it here (including the definition of
'struct x').  For C++, you would decide that vtable definitions come
"before" everything else, so debug information gets output with the
vtable if there is one.

The idea is that it doesn't need to be perfect, since duplicate
information is harmless; just so long as you can eliminate most of the
duplicates.

-- 
- Geoffrey Keating <geoffk@geoffk.org>