Re: When to emit C++ debug info?

[Daniel Berlin <dberlin at dberlin dot org>]

On Jan 5, 2004, at 12:24 PM, Joe Buck wrote:

> On Jan 3, 2004, at 8:05 PM, Chris Lattner wrote:
> > > Why not always do #2, and have the linker eliminate the duplicate
> > > information?
>
> On Sat, Jan 03, 2004 at 07:57:21PM -0500, Daniel Berlin wrote:
> > This is of course, the right solution in all but the weirdest cases.
> > Unfortunately, making BFD do this is well, non-trivial, to say the
> > least.
>
> No, it's not the right solution, as it explodes the disk space needed 
> for
> the .o files as well as the time and memory required for doing the 
> link.
> A fast compile-link-debug cycle is critical, and it's been the major 
> failing
> of GCC over the years.  At this point, we should be careful to make 
> sure
> that we do not make the problem worse.
At the same time, we simply can't pretend that making everyone include 
debug info is a "solution".


> We can build on the cfront virtual function table heuristic: only emit
> debug information for a class in the unit that implements the virtual
> function table.  "But someone might give me a library with no debug
> information".  Fine, we can have a flag that causes full debug info
> to be emitted to cover that case, but it should not be the default.

This is a broken solution, because you don't get the debug info you 
need without passing special flags.  You end up having to rebuild when 
you notice your library didn't include debug info (which is the common 
case, not the exceptional case).
And then you have no fast compile-link-debug cycle again anyway, just 
because someone handed you a library without debug info.

I'll simply note that compilers which provide fast compile-link-debug 
cycles (MSVC for instance) usually use some kind of separated debug 
info to do this (and eliminate as they compile), and *not* heuristics.

But since nobody seems to agree, i'll simply go away.

--Dan