This is the mail archive of the
mailing list for the GCC project.
Re: LTO inhibiting dwarf lexical blocks output
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: 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: Fri, 15 Aug 2014 22:13:26 +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>
- Reply-to: Jakub Jelinek <jakub at 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.