On Fri, Feb 6, 2015 at 5:42 PM, Aldy Hernandez <al...@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.
