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

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, Feb 6, 2015 at 5:42 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
>
>>> +    && DECL_CONTEXT (snode->decl)
>>> +    && TREE_CODE (DECL_CONTEXT (snode->decl)) != FUNCTION_DECL)
>>
>>
>> I think this should be !decl_function_context (snode->decl), in case
>> there's a class or BLOCK between the symbol and its enclosing function.
>
>
> Done, also for the iteration through reachable functions.
>
>>
>>>  dwarf2out_type_decl (tree decl, int local)
>>> +  /* ?? Technically, we shouldn't need this hook at all, as all
>>> +     symbols (and by consequence their types) will be outputed from
>>> +     finalize_compilation_unit.
>>
>>
>> Note that we also want to emit debug info about some types that are not
>> referenced by symbols, such as when a type is used in a cast.
>
>
> Fair enough.  I've removed the comment.
>
>>> +/* Perform any cleanups needed after the early debug generation pass
>>> +   has run.  */
>>> +
>>> +static void
>>> +dwarf2out_early_finish (void)
>>
>>
>> Since this is also called from dwarf2out_finish, let's call it something
>> more descriptive, say, flush_limbo_dies?
>
>
> I was actually thinking of using dwarf2out_early_finish() to mop things up
> as we generate early (or stream out) other auxiliary tables (pubname_table,
> pubtype_table, file_table, etc).  More details on that later.  If so, can I
> leave it as is?
>
> How is this version?  No regressions on guality.  Target libraries build
> fine.

Finally having a look at the patch.  And indeed - this is how I thought
it should work.

Of course I wonder why you need to separate handling of functions and
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.

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)

Likewise for

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

and I realize that this needs frontend support - the middle-end really
only gets "reachable" stuff reliably.

Thus for -g3 we may end up retaining (or adding) some FE calls
to early_global{_decl,_type}?

(not that I care about the above cases in practice, but in theory?)

Thanks for doing all this work!

Richard.