Re: [PATCH] Fix flag_eliminate_dwarf2_dups/flag_eliminate_unused_debug_types clash

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> > > > 	* dwarf2out.c (dwarf2out_finish): Swap break_out_includes and
> > > > 	prune_unused_types order.
> > > 
> > > I guess this is ok, but I think it more useful to turn off
> > > flag_eliminate_unused_debug_types when flag_eliminate_dwarf2_dups.
> > 
> > this patch puts types into their own sections in case
> > both flag_eliminate_unused_debug_types and flag_eliminate_dwarf2_dups
> > are used, so that they do not conflict with each other. It always does
> > this for basic types with flag_eliminate_dwarf2_dups (they are usually
> > defined in all object files). The results (sizes of cc1 compiled with
> > various flag combinations):
> 
> Zdenek, I'd like to ask you a question about -feliminate-dwarf2-dups. 
> It's not new with this patch, but I think it'll get worse.
> 
> Is there any way for a debugger to reconstruct what types are visible
> in a given source file?  Or what headers were included?  It looks like
> the BINCL/EINCL tags are never emitted and there are no references to
> the header file's entire CU from the main CU.
> 
> Scanning the spec it looks like the anonymous CUs should be
> DW_TAG_partial_unit instead of DW_TAG_compile_unit and we should be
> using DW_TAG_imported_unit.

I really don't know. The code for -feliminate-dwarf2-dups is not mine (I
just fixed it a few times), and my knowledge of dwarf2 spec is not good
enough to answer your question.

Considering usability:
1) gdb does not support multiple CU's at all (it cannot resolve
references across CU boundaries)
2) but it is patchable. I have a hack for it somewhere, but it no longer
applies. I did not try to push it into official gdb, because I have seen
some mails indicating that the support is being added to it (in much
cleaner way than my patch). But evidently it got stuck somewhere.

Zdenek