This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [debug-early] LTO streaming of on-the-side dwarf data structures
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>
- Cc: jason merrill <jason at redhat dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>, Andrew MacLeod <amacleod at redhat dot com>
- Date: Wed, 15 Oct 2014 09:58:16 +0200
- Subject: Re: [debug-early] LTO streaming of on-the-side dwarf data structures
- Authentication-results: sourceware.org; auth=none
- References: <543C72D6 dot 90100 at redhat dot com> <CAFiYyc1e4zeeZ2nH9RgLENdSErrdNWc+87e3BToZ-+zjJBiqaw at mail dot gmail dot com> <543D8292 dot 4000803 at redhat dot com> <543D8855 dot 9090300 at redhat dot com>
On Tue, Oct 14, 2014 at 10:32 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
>
>> Another similar issue I've seen is handling DW_TAG_lexical_block
>> (gen_lexical_block_die). Ideally we should generate the
>> DW_TAG_lexical_block and the corresponding locals in early dumping, and
>> then fill in the high/low attributes of the lexical block the second
>> time around. We would need a hash similar to decl_die_table to get from
>> BLOCK->DW_TAG_lexical_block, similar to die_table_offset. For that
>> matter, we could store the relationship in die_table_offset, or in the
>> die_offset if I understood things correctly.
>
>
> Errr, we can't store a TREE->DW_TAG_lexical_block relationship in
> die_table_offset cause we don't have a DECL_UID. So we need another
> mechanism.
Either put a pointer into TREE_BLOCK or use a combination of
BLOCK_NUMBER (hopefully that's stable - aww, it doesn't look like so)
and its function context decl UID. A pointer-map also works, of course.
Richard.
> Aldy