This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: When to emit C++ debug info?
On Mon, Jan 05, 2004 at 09:24:25AM -0800, 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.
>
> 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.
I believe the summary of my arguments at this point is, the use of C++
libraries without debug info is a great deal more common than GCC
developers believe - in fact, it's probably pretty much standard.
As an example, people who are concerned about disk space and link time
are probably building their huge, multiple-library projects without
debug info; then when they want to debug an application they rebuild
that application with debug info. Having to rebuild the library would
be a major nuisance.
However it is clear that at least two maintainers disagree with my plan
for usable debug info for performance reasons. Therefore I am going to
go away until I have enough time to implement this and can provide
measurements.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer