[cfe-dev] r222220 causes real debug-info bloat

Robinson, Paul Paul_Robinson at playstation.sony.com
Fri May 1 17:29:30 PDT 2015

We were doing some size analysis and noticed some ridiculous numbers
related to debug-info size.  Investigation showed that essentially all 
of the bloat came from DW_TAG_imported_declaration pointing to 
DW_TAG_subprogram and the associated DW_TAG_formal_parameter DIEs.  
We tracked this to r222220, which basically caused every 'using' decl
of a function or variable to have a forward declaration emitted to the
DWARF, whether or not that 'using' decl itself was used in the CU.

#include <stdlib.h>
using ::abort

In Clang 3.5, this produces a pretty minimal .debug_info section (just
the DW_TAG_compile_unit).
In Clang 3.6, we see an additional DW_TAG_subprogram for abort() and then
a DW_TAG_imported_declaration pointing to that declaration.

#include <cstdlib>

on Linux, Clang 3.5 wrote a .debug_info of 185 bytes, 3.6 was 1458.

Multiply this by more headers and again by hundreds to thousands
of modules and pretty soon you're talking multiple megabytes.
Getting away from the benchmarks, a real game saw .debug_info increase
by 13% (6 MB).

r222220 basically causes a 'using' declaration of a function or global
variable to conjure up a forward declaration, if we haven't already 
seen a declaration or definition.  The commentary talks about how this 
will be RAUW'd later on.  But I'm not sure what motivated this in the 
first place, and it clearly can have a huge adverse effect.

I don't mind having a DW_TAG_imported_declaration for something that
actually gets used in the CU, but a 'using' declaration all by itself
should not count as "used" for purposes of emitting debug info.

Can somebody describe how these extra forward declarations fit into
the Grand Scheme of Things in a beneficial way, and can we do something
about unused 'using' declarations?

Given how the patch works, it looks we can just short-circuit the
creation of these forward declarations with no harm done, but I have to
wonder whether we're shooting ourselves in the foot in some situation
that isn't immediately obvious.


More information about the cfe-dev mailing list