Re: [patch] better dwarf2 debug info for inlined functions

[James E Wilson <wilson at specifix dot com>]

Mike Stump wrote:
> I'll say it.  Our competition produces debug information around 16x  
> smaller.

This can easily lead to apples and oranges type comparisons.  The size 
of the debug info depends on a number of factors
1) How much optimization is being performed.
2) How accurately the debug info describes the optimized output.
3) How compact the debug info is.


One and two are probably going to increase over time, and improvements 
to three may not be able to keep up.


Also, Apple is using stabs, but the subject line says dwarf2, and these 
are very different things with different problems.  dwarf2 info is 
already compacted.  stabs is not.  We already have working duplicate 
removal for stabs.  We don't for dwarf2, though I think we have most of 
the infrastructure.

If you really want smaller debug info, then one of the most useful 
things you can do is compile with lower optimization levels.  Another 
alternative here is to emit smaller less useful debug info.  We already 
have the -g1 option that emits a subset of debug info.  This could 
perhaps be expanded to have other choices for debug info subsets.

Past that, I think the Sun approach is a good one.  Sun leaves the debug 
info in the object files.  They don't get linked, which saves time and 
space creating the executable.  This means the debugger needs to be able 
to read the debug info from object files instead of the executable, 
which means someone will have to volunteer to do the gdb work.

>    1   Repository

I'm not familiar with C++ repositories, but if this is anything like the 
Sun approach then this may be useful.

>    2   Compression

dwarf2 is already designed to be compact.  We are missing duplicate 
removal, which we have for stabs.  Past that, we could do some extra 
compaction in the linker if we decoded the debug info, and then 
re-encoded it, but that would take a lot of time and space and may not 
be worthwhile.  This is a place where the compact format hurts us, as it 
makes it harder to do link time optimizations of the debug info.  But if 
we take the Sun approach, then we don't need any linking anyways.

Maybe you mean something like gzip the debug info sections here?  Crude, 
but it could be effective.

>    3   Elimination of stuff the user doesn't need

Since you don't know what debugger commands the user will want to use, 
it is hard to know what they don't need.  But certainly we could try 
offering levels of debug info, sacrificing accuracy for space.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com