On 02/10/2015 02:52 AM, Richard Biener wrote:
On Fri, Feb 6, 2015 at 5:42 PM, Aldy Hernandez <al...@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
