Re: stabs vs. dwarf-2 for C programs

[Daniel Berlin <dan at cgsoftware dot com>]

Ian Lance Taylor <ian@zembu.com> writes:

> 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.

Effectively, you are saying "Linking without linking some of the info,
makes it faster".
Of course it does.

And if you just had the linker merge all the debug info, and throw it
in a file, but not link the objects, it'd be faster, too.
However, it's not linking.
With things like dwarf2 dupe elimination implemented in compilers
using linkonce sections, and relocations on debug info in object
files, leaving the debugging info  in the object files, is simply
impossible.  It's a hack. Nothing more or less. 

Why don't we try actually optimizing the reading/writing of files in
ld?

Other linkers are tons faster on the same size executables, without
doing what he proposes.

I suspect there is a reason for this.
> 
> Ian

-- 
I was in the grocery store.  I saw a sign that said "pet
supplies."  So I did.  Then I went outside and saw a sign that
said "compact cars"...