Re: stabs vs. dwarf-2 for C programs

[Ian Lance Taylor <ian@zembu.com>]

Daniel Berlin <dan@cgsoftware.com> writes:

> > The native Sun Solaris linker takes an interesting approach
> > to eliminating duplicate debugging information.  It does
> > not copy much debug information from the original object
> > module to the final linked product, just enough to identify
> > which original object contains the debugging information.
> > The debugger then needs to locate the original object module
> > when setting breakpoints or looking up symbol information.
> > The only downside is that this prevents much symbolic debugging
> > if the original built objects aren't around.  It can also
> > speed the link not only by not having to rewrite symbolic
> > debug information, but also by not having to read it in the
> > original objects.  It also speeds up starting the debugger,
> > as the debugger no longer has to read the entire symbol table
> > at startup.
> 
> We already don't do this anyway, without needing to do this kind of
> hairy trick.
> 
> DWARF2 was made to be able to be quickly scanned, and not entirely
> loaded all at once.

That's fine for the debugger, but not for the linker.  The GNU linker
still has to actually read the bytes from the object files and write
them into the executable.  Using DWARF, the debugging information can
easily be much larger than the actual executable code.  Skipping
reading and writing all the data can speed up the link step
significantly--by at least a factor of two.

Speeding up link times by a factor of two while retaining the ability
to do full debugging can significantly speed up the compile/link/debug
cycle.

Ian