| Message ID | 54E61314.9070805@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Thu, Feb 19, 2015 at 08:45:08AM -0800, Aldy Hernandez wrote: > [And this time, actually CCing the list :)]. > > Gentlemen! > > Reading in the compiler state for pch (gt_pch_restore) obliterates the > DIE table, and consequently the DW_TAG_GNU_[BE]INCL* DIEs that may have > been in it. This causes inconsistencies when reading in _any_ > pre-compiled header into a source file that uses > -feliminate-dwarf2-dups, and consequently already has some > DW_TAG_GNU_[BE]INCL* DIEs. > > Normally the DIE table should be empty this early on, especially since > mainline generates dwarf at the end of the compilation unit, but the DIE > table may have DW_TAG_GNU_[BE]INCL* DIEs that were created early by > dwarf2out_start_source_file/etc or it may have the DW_TAG_compile_unit. > > I suppose we could merge incoming DIEs with existing DIEs and complicate > our lives, but considering we will probably have to tackle this in the > debug-early work, I propose we disable this combination for now (and > possibly permanently, unless we really care about it). > > OK for mainline pending tests? Wouldn't it be better to disable PCH reading if -feliminate-dwarf2-dups is used? I mean, fail to read the PCH silently (or with warning for -Wpch or what the warning is about why PCH couldn't be read or was ignored), perhaps error out if you try to generate PCH with -feliminate-dwarf2-dups? Jakub
On 02/19/2015 11:50 AM, Jakub Jelinek wrote: > Wouldn't it be better to disable PCH reading if -feliminate-dwarf2-dups > is used? In the abstract, perhaps, but given https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53118 I'd prefer to disable the useless thing. :) We might actually disable -feliminate-dwarf2-dups entirely until that bug is fixed. Jason
diff --git a/gcc/c-family/c-pch.c b/gcc/c-family/c-pch.c index 0ede92a..6b442e2 100644 --- a/gcc/c-family/c-pch.c +++ b/gcc/c-family/c-pch.c @@ -381,6 +381,23 @@ c_common_read_pch (cpp_reader *pfile, const char *name, timevar_pop (TV_PCH_CPP_RESTORE); gt_pch_restore (f); + + /* At pre-compiled header output time, we may have outputted a few + DIEs corresponding to DW_TAG_GNU_[BE]INCL. Reading the compiler + state above will read in these DIEs, and obliterate any + DW_TAG_GNU_[BE]INCL so far generated. + + Disable this combination for now. When early debug generation is + implemented, we can probably get this combo to work. */ + if (flag_eliminate_dwarf2_dups) + { + warning_at (UNKNOWN_LOCATION, 0, + "Pre-compiled headers cannot be used with -feliminate-dwarf2-dups."); + warning_at (UNKNOWN_LOCATION, 0, + "-feliminate-dwarf2-dups has been disabled."); + flag_eliminate_dwarf2_dups = 0; + } + cpp_set_line_map (pfile, line_table); rebuild_location_adhoc_htab (line_table);
[And this time, actually CCing the list :)]. Gentlemen! Reading in the compiler state for pch (gt_pch_restore) obliterates the DIE table, and consequently the DW_TAG_GNU_[BE]INCL* DIEs that may have been in it. This causes inconsistencies when reading in _any_ pre-compiled header into a source file that uses -feliminate-dwarf2-dups, and consequently already has some DW_TAG_GNU_[BE]INCL* DIEs. Normally the DIE table should be empty this early on, especially since mainline generates dwarf at the end of the compilation unit, but the DIE table may have DW_TAG_GNU_[BE]INCL* DIEs that were created early by dwarf2out_start_source_file/etc or it may have the DW_TAG_compile_unit. I suppose we could merge incoming DIEs with existing DIEs and complicate our lives, but considering we will probably have to tackle this in the debug-early work, I propose we disable this combination for now (and possibly permanently, unless we really care about it). OK for mainline pending tests? Aldy commit c0814b101417a5639fe70b41526b4e2d7a56ee52 Author: Aldy Hernandez <aldyh@redhat.com> Date: Thu Feb 19 07:35:59 2015 -0800 PR debug/46102 * c-pch.c (c_common_read_pch): Disable -feliminate-dwarf2-dups if reading a pre-compiled header.