This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: stabs vs. dwarf-2 for C programs


Daniel Berlin <dan@cgsoftware.com> writes:

> > If you are leaving debug info in object files, I don't understand why
> > you would do elimination of debug info. 
> 
> Errr, because the memory usage in the debugger will jump otherwise.

You would certainly have to read more information from the object
files, but I would assume that the debugger could easily discard
information it already had.  I would not expect the debugger memory
usage to increase by more than 30%.

Anyhow, I freely concede that the debugger will be slower and will
require more memory.

> Unless you suggest we do the elimination in the debugger?
> I tried this, and it worked fine on the memory issue, but people just
> complained about the executable size anyway. :)

Well, yes, but in the case we are discussing they would hardly do
that.

> > > > 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. 
> Depends, I guess.
> I find i run the debugger as much as the linker, but i deal with
> either gcc, gdb, or hairy multithreaded programs that seem to not do
> the locking they need to :)

Obviously this optimization would be optional.  Different people would
have different choices.

Even if you run the debugger exactly as often as you run the linker,
if you only debug a small part of the program, the debugger should
only have to read and parse a small portion of the debugging
information.  You might still win overall with the improvement in link
time.

> I can't think of many cases where it *is* a good tradeoff, unless you
> almost never debug, in which case, why the heck are you doing debug
> builds anyway?

Clearly we have very different approaches to development.

I run the debugger relatively rarely during development.  I normally
debug by examining the program behaviour and examining the program
code.  I normally use the debugger for examinations of core files, and
when I am stuck.

I run the linker far more often than the debugger, but that doesn't
mean that I don't want to be able to run the debugger when I need it.
I don't want to have to go do a link merely in order to debug.

> > 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.
> 
> This has to be much lower than the cost of reading and writing other
> sections. There is nothing much to process.

The only real processing the linker does is symbol table handling and
relocation processing.  DWARF debugging sections don't have many
symbols, but they have plenty of relocations to process.

> I would imagine
> that debug info sections probably take the least amount of time to
> process of all the sections, and that section time processing is
> dominated by a few section types that require more than just "read
> huge chunk->process huge chunk->write huge chunk whenever we flush for
> some reason".  I could be completely off the mark, of course.

I think you are.  There aren't really any section types which require
significant special processing, and they certainly don't dominate the
link time.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]