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

Of course not, unless you perform elimination of debug info, in which
case, it can be impossible without having to recompile possibly every
object, every time (see below).


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

Yes. It requires the debugger to become a linker.
You haven't removed the time necessary, you've simply moved it to
another place, excluding disk write time from the end of link pass.

But mainly, it means you have to
do dwarf2/stabs elimination across object files, which makes those object files
potentially useless on the next compile.
What happens if one of the changes to one of the source files causes a
class to suddenly not appear in that object file (which can happen due
to deferred output and whatnot.  You don't instantiate a template
class anymore, by removing a usage of std::string, or something) , and
the elimination had chosen to eliminate all instances of std::string's
debug info, except that one, on the previous link?

Now yer screwed.

This is because DWARF2 elimination isn't based on include file
elimination, it's based on the equivalence of die's (though this could
be changed, if necessary, at the cost of making object files bigger,
because it would mean not deferring output of debug info, as gcc does
now, instead outputting everything we see, so that including a file
gives you the same debug info no matter what code you write)

And what about constructor sections, or destructor sections?
Or sections that only get merged by the linker?

You need to do the same amount of linking, you've just spread the time
around, and removed the time necessary to write (probably at the cost
of memory) the final executable.

In fact, that's all this approach saves. The cost of writing. We still
eat the cost of reading, and the cpu usage, and we have to perform the
linking/relocation somewhere, so we eat as much memory, as you would disk.

Unless you only use C, of course, in which case this is a perfectly
valid approach.


> How
>   I honestly don't
> know why you are so critical. 

Because I don't want GDB to turn into a linker. 

>  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.
Of course not. I'm sure they have.
But times change, disk speeds change, memory speeds change, and
bottlenecks change.  

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

I believe Ulrich is doing this.
>   The current linker is very
> flexible, which is good, but that flexibility slows it down for the
> most common uses.

Correct.

It also doesn't support a lot of things that are nice for disk i/o
dominated programs like linking. These days, they are dominated by
seek time, and we do *tons* of seeks in bfd.  We'd be better off using
mmap if possible (file windows aren't the answer, just map the file
when open, unmap when close, and if a flag in the bfd structure says
it's mapped, use the right memory functions).

I'm pretty sure this alone will cut linking time by a large factor,
based on the number of seeks and the amount of time they are taking,
in a few tests i just did.

> 
> Ian

-- 
I went to the cinema, and the prices were:  Adults $5.00,
children $2.50.  So I said, "Give me two boys and a girl."