Re: stabs vs. dwarf-2 for C programs

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

Daniel Berlin <dan@cgsoftware.com> writes:

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

Huh?  Leaving the debugging information in object files is clearly not
impossible.  You need a minimal amount of debugging information in the
executable: enough for it to determine which object file to check for
information about a particular address range.  That is not impossible.
The debugger needs to process relocations at debug time.  That is not
impossible.

Do you have a valid reason to reject this approach?  I honestly don't
know why you are so critical.  This is doable, and it would help.

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

Yes, if that's true, I'm sure there are reasons, and as the single
person most responsible for the present GNU linker code, it's quite
possible that any such reasons can be traced directly to me.

But I hope you don't think that nobody has ever tried to optimize the
linker.  In fact, I've spent months on it.  At one time, around 1995
or 1996, the speed of the linker was within 50% of the speed of cat
(on SunOS, for a.out).  However, the addition of shared library
support has definitely slowed the linker down, as in the current
regime ELF relocations are processed twice--once to build the PLT and
GOT, and once to actually perform the relocations.  At the time I
implemented it, I couldn't figure out an alternate approach.  Perhaps
we can do so, with much more knowledge and familiarity with the
requirements.

Actually, as I've said before, I think the correct approach right now
is to write an ELF specific linker.  The current linker is very
flexible, which is good, but that flexibility slows it down for the
most common uses.

Ian