This is the mail archive of the
mailing list for the GCC project.
Re: LTO inhibiting dwarf lexical blocks output
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Steven Bosscher <stevenb dot gcc at gmail dot com>, Aldy Hernandez <aldyh at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Mon, 18 Aug 2014 02:17:00 +0200
- Subject: Re: LTO inhibiting dwarf lexical blocks output
- Authentication-results: sourceware.org; auth=none
- References: <53EE66B1 dot 7040105 at redhat dot com> <CABu31nOspsrCyAJt6dntdFZpq9iQVKOw=Vr0TLDKW3OJ0==VkQ at mail dot gmail dot com> <20140815201326 dot GV1784 at tucnak dot redhat dot com>
> On Fri, Aug 15, 2014 at 10:08:38PM +0200, Steven Bosscher wrote:
> > On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
> > > So... I've been getting my feet wet with LTO and debugging and I noticed a
> > > seemingly unrelated yet annoying problem. On x86-64,
> > > gcc.dg/guality/pr48437.c fails when run in LTO mode.
> > Eh, sorry I can't actually answer your question but, eh...
> > Isn't the only real solution: to generate this kind of DIEs earlier
> > (maybe already immediately after parsing) and stream them?
> > Otherwise, how can this possibly be made to work with multi-language LTO?
> > It seems to me that only the lowest-level DWARF (things we don't know
> > about until RTL, like CFI) should be done at link time. Things like
> > scoping and types are language dependent and have to be generated
> > before streaming.
> > Again, sorry for not actually being helpful - just a thought ;-)
> The plan is indeed to generate as much DWARF as possible early.
> But, BLOCKs are something which if you throw away during compilation like
> LTO does right now will never work properly, because while some minimal
> DWARF tree can be created for it early, for the lexical block to be useful you need
> to track on which exact instructions the lexical block is in scope and on
> which it is not.
We do get blocks at LTO and variables in BLOCK_VARs list, just global decls are skipped
(because they are linked by chain pointer and one decl thus can not appear in multiple lists
and decl merging will make that happen)
I would expect the early DWARF to already contains its representation of BLOCK_VARS at least
for the global decls. If that is undobale we can always link BLOCK_VARs by vector instead
of tree chain and fix this issue.