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

[Frédéric Riss]

Hi!

> On May 1, 2015, at 5:29 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote:
> 
> 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.

The whole story is that I was working on getting debug info emitted
for function argument default values (which I haven’t gotten back to
yet BTW), and that my implementation didn’t work if the default value
was a call to a forward declared function. Our decl tracking didn’t
handle forward declarations at all, and David pointed out that this
was why we were also missing some DW_TAG_imported_declaration. I
then implemented support for forward declarations and tested it using
the the only current user that cared about forward decls, that is the
imported_declaration stuff.

> 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.

It’s not that the using clause counts as a ‘use’, it’s just a
question of source fidelity. Your above example isn’t really
compelling. By changing it a little bit to:

#include <stdlib.h>

namespace A {
using ::abort;
}

The goal of the imported_declaration information is to inform
the debugger that in this CU, A::abort is the same thing as 
::abort. It’s just a matter of describing aliased name to
the debugger so that it can correctly evaluate source
expressions.

> 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?

I totally get your point about the size, and according to past
conversations, I gather that the use described above isn’t maybe
relevant to your debugger (which maybe points to something that
can be tuned depending on the target debugger? I’m sorry, but I
just came back from a long leave and I’m so much behind on list
reading that I have no idea of the status of that idea).

IMO, it has nothing to do with the fact that the function/variable
is used or not. The using directives create new names and the only
way for the debugger(s) to understand these names is to have them
described in the debug info.

> 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.

If the git commit message is still accurate regarding the use of that
function, then you’ll just go back to the previous state which you
liked better. If the function grows new callers, you might lose
more stuff, but IIUC it should mostly be stuff that you don’t care
about anyway.

Fred


> Thanks,
> --paulr
>