Re: [debug-early] C++ clones and limbo DIEs

[Aldy Hernandez <aldyh at redhat dot com>]

On 02/10/2015 02:52 AM, Richard Biener wrote:
> On Fri, Feb 6, 2015 at 5:42 PM, Aldy Hernandez <aldyh@redhat.com> wrote:

> Of course I wonder why you need to separate handling of functions and variables

The variables need to be handled earlier, else the call to 
analyze_functions() will remove some optimized global variables away, 
and we'll never see them.  I believe that Jason said they were needed 
up-thread.

> variables.  What breaks if you emit debug info for functions before
> the first analyze_functions () call?
>
> I also wonder why you restrict it to functions with a GIMPLE body.

The functions, on the other hand, need to be handled after the second 
call to analyze_function (and with a GIMPLE body) else we get far more 
function DIEs than mainline currently does, especially wrt C++ clones. 
Otherwise, we get DIEs for base constructors, complete constructors, and 
what-have-yous.  Jason wanted less DIEs, more attune to what mainline is 
currently doing.

> I'd have expected for a TU like
>
> void foo (int, int);
> int main()
> {
>    return 0;
> }
>
> to be able to do
>
> (gdb) start
> (gdb) ptype foo
>
> and get a prototype for foo?  (ok, that may be -g3 stuff)

This may need frontend support.  I don't think we get any of these 
prototype symbols in cgraphunit, at least not in the symbol table 
(FOR_EACH_SYMBOL).  Perhaps a call from the front-ends, similar to what 
we do with types with debug_hooks->type_decl().  But... do really want 
that?  Is there a practical use?

> Likewise for
>
> struct foo { int i; };
> int main ()
> {
>    return 0;
> }

This is already working if compiled with 
-fno-eliminate-unused-debug-types, probably by virtue of types being 
called from the front-ends with debug_hooks->type_decl().  We could 
certainly enable -fno-eliminate-unused-debug-{symbols,types} for -g3 if 
desirable.

> Thanks for doing all this work!

Thanks for volunteering to do the LTO bits ;-).

Aldy