This is the mail archive of the
mailing list for the GCC project.
Re: [patch] better dwarf2 debug info for inlined functions
Mike Stump wrote:
I'll say it. Our competition produces debug information around 16x
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
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