Re: [PATCH][1/n] dwarf2out refactoring for early (LTO) debug

[Richard Biener <rguenther@suse.de>]

On Wed, 19 Aug 2015, Richard Biener wrote:

> On Tue, 18 Aug 2015, Aldy Hernandez wrote:
> 
> > On 08/18/2015 07:20 AM, Richard Biener wrote:
> > > 
> > > This starts a series of patches (still in development) to refactor
> > > dwarf2out.c to better cope with early debug (and LTO debug).
> > 
> > Awesome!  Thanks.
> > 
> > > Aldyh, what other testing did you usually do for changes?  Run
> > > the gdb testsuite against the new compiler?  Anything else?
> > 
> > gdb testsuite, and make sure you test GCC with --enable-languages=all,go,ada,
> > though the latter is mostly useful while you iron out bugs initially.  I found
> > that ultimately, the best test was C++.
> 
> I see.
> 
> > Pre merge I also bootstrapped the compiler and compared .debug* section sizes
> > in object files to make sure things were within reason.
> > 
> > > +
> > > +static void
> > > +vmsdbgout_early_finish (const char *filename ATTRIBUTE_UNUSED)
> > > +{
> > > +  if (write_symbols == VMS_AND_DWARF2_DEBUG)
> > > +    (*dwarf2_debug_hooks.early_finish) (filename);
> > > +}
> > 
> > You can get rid of ATTRIBUTE_UNUSED now.
> 
> Done.  I've also refrained from moving
> 
>   gen_scheduled_generic_parms_dies ();
>   gen_remaining_tmpl_value_param_die_attribute ();
> 
> for now as that causes regressions I have to investigate.

Tricky beast ;)  For g++.dg/debug/dwarf2/template-func-params-3.C
we run into the issue that when doing early dwarf the
rtl_for_decl_init (&bleh) call will fail because it ends up asking

15809              && ! walk_tree (&init, reference_to_unused, NULL, NULL)

which uses TREE_ASM_WRITTEN to see of 'bleh' was emitted or not.
That's not going to work at this stage - we even have no idea
whether 'bleh' is going to survive IPA or not (might be inlined).
With LTO it gets even tricker as we only see a subset of the whole
program (or original TU) at LTRANS stage.

So it somehow looks like late dwarf thing for this kind of
symbolic constants - but it _also_ looks like a very bad
dwarf representation to me (going through RTL is bad enough, heh).
We expect DW_OP_addr and a reference to _Z4blehv as follows:

        .byte   0x3     # DW_OP_addr
        .quad   _Z4blehv

but I wonder if DWARF has something better so we can refer
to _Z4blehv by means of the DIE for its declaration (so the
debugger can resolve the constant value)?  That would allow
the debugger to print &bleh even if bleh was optimized out
(it just would have to print <optimized out> for the actual
address).

So what I'll do is have two phases of
gen_remaining_tmpl_value_param_die_attribute 
(gen_scheduled_generic_parms_dies doesn't have a similar issue
AFAICS), during early-debug add those we can, retaining those
we can only handle late (just checking the return value of
tree_add_const_value_attribute).  For LTO the remaining ones
will be dropped on the floor (or we'd have to stream them
somehow) unless we can change the DWARF representation of
these symbolic constants.

Thanks,
Richard.