This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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,

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