Re: stabs vs. dwarf-2 for C programs

[Ian Lance Taylor <ian at zembu dot 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.  
> 
> 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).

If you are leaving debug info in object files, I don't understand why
you would do elimination of debug info.  The goal of leaving debug
info in object files is to speed up the linker at the expense of the
debugger.  The usual purpose of eliminating debug info is to shrink
the size of the executable (which does not apply) and to speed up the
debugger at the expense of the linker (which does not apply).

Is there some other reason to eliminate debug info?

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

Well, yes.  That's the whole point.  The linker is run more often than
the debugger.  Quite a bit more often, in fact.  It can be a good idea
to speed up the linker at the expense of the debugger.

It doesn't require the debugger to become a full-fledged linker, of
course.  It only requires the debugger to process the simple
relocations which can appear in debugging sections.  This is fairly
easy, and in fact BFD provides a function which does it.

[ I omit further discussions about debug info elimination, since I
  don't understand why you would do it when leaving debug info in
  object files. ]

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

I give up.  What about them?

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

No.  The approach saves the cost of reading the debug information from
the files, it saves the cost of processing the debug information for
duplicate information, it saves the cost of processing debug
information relocations, and, as you say, it saves the cost of writing
the debug information.

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

It's possible.  Around 1997 or so I tried using mmap as you suggest.
It actually made the linker slower on the systems I tested it on,
including Solaris and on the Linux kernel, so I dropped the effort.
But, as you say, times change, and maybe now it would indeed be
faster.  It's an easy optimization in BFD; why don't you try it?

Ian