https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #10)
> (In reply to Richard Biener from comment #9)
> > Created attachment 44729 [details]
> > patch
> >
> > This avoids most of the forwarders (slightly hackish) and adds linkage
> > names.
> >
> > gdb startup is faster, more testing is in progress.
>
> Hm. Looks like we hit
>
> Reading symbols from ../../obj3/gcc/lto1...done.
> ../../gdb/dictionary.c:690: internal-error: void
> insert_symbol_hashed(dictionary*, symbol*): Assertion `SYMBOL_LANGUAGE (sym)
> == DICT_LANGUAGE (dict)->la_language' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n)
>
> with the patch which somehow feels familiar ...
>
> The performance testing was on an earlier patch w/o the abstract-origin fixes
> (just on-demand DIE creation).
>
> The above also reproduces with gengtype (but not with a simple test).
OK, also genchecksum. We see that for example on
Compilation Unit @ offset 0x20a2:
Length: 0x3b4 (32-bit)
Version: 4
Abbrev Offset: 0x83c
Pointer Size: 8
<0><20ad>: Abbrev Number: 1 (DW_TAG_compile_unit)
<20ae> DW_AT_producer : (indirect string, offset: 0xe27): GNU C17
9.0.0
20180919 (experimental) [trunk revision 259470] -mtune=generic -march=x86-64
-g -O2 -flto=jobserver -frandom-seed=1
<20b2> DW_AT_language : 12 (ANSI C99)
<20b3> DW_AT_name : (indirect string, offset: 0x1020):
/tmp/trunk/libiberty/xstrerror.c
...
<2><244c>: Abbrev Number: 18 (DW_TAG_variable)
<244d> DW_AT_name : (indirect string, offset: 0x1019): errstr
<2451> DW_AT_decl_file : 7
<2452> DW_AT_decl_line : 56
<2453> DW_AT_decl_column : 9
<2454> DW_AT_type : <0x2122>
Compilation Unit @ offset 0x245a:
Length: 0x8df (32-bit)
Version: 4
Abbrev Offset: 0x93f
Pointer Size: 8
<0><2465>: Abbrev Number: 1 (DW_TAG_compile_unit)
<2466> DW_AT_producer : (indirect string, offset: 0x1090): GNU GIMPLE
9
.0.0 20180919 (experimental) [trunk revision 259470] -mtune=generic
-march=x86-6
4 -mtune=generic -march=x86-64 -g -O2 -O2 -fno-openmp -fno-openacc
-frandom-seed
=1 -fno-exceptions -fasynchronous-unwind-tables -fno-common -fno-PIE -fltrans
<246a> DW_AT_language : 4 (C++)
<246b> DW_AT_name : (indirect string, offset: 0x106e):
<artificial>
...
<1><2589>: Abbrev Number: 2 (DW_TAG_subprogram)
<258a> DW_AT_abstract_origin: <0x2434>
<258e> DW_AT_linkage_name: (indirect string, offset: 0x1041): xstrerror
<2592> DW_AT_low_pc : 0x401300
<259a> DW_AT_high_pc : 0x28
<25a2> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<25a4> DW_AT_GNU_all_call_sites: 1
<25a4> DW_AT_sibling : <0x264b>
...
<2><25b5>: Abbrev Number: 4 (DW_TAG_variable)
<25b6> DW_AT_abstract_origin: <0x244c>
<25ba> DW_AT_location : 0xfae (location list)
<25be> DW_AT_GNU_locviews: 0xfaa
<1><2c4f>: Abbrev Number: 22 (DW_TAG_imported_unit)
<2c50> DW_AT_import : <0x20ad> [Abbrev Number: 1]
maybe because we "merge" languages in gen_compile_unit_die:
/* If our producer is LTO try to figure out a common language to use
from the global list of translation units. */
if (strcmp (language_string, "GNU GIMPLE") == 0)
{
unsigned i;
tree t;
const char *common_lang = NULL;
FOR_EACH_VEC_SAFE_ELT (all_translation_units, i, t)
{
if (!TRANSLATION_UNIT_LANGUAGE (t))
continue;
if (!common_lang)
common_lang = TRANSLATION_UNIT_LANGUAGE (t);
else if (strcmp (common_lang, TRANSLATION_UNIT_LANGUAGE (t)) == 0)
;
else if (strncmp (common_lang, "GNU C", 5) == 0
&& strncmp (TRANSLATION_UNIT_LANGUAGE (t), "GNU C", 5) ==
0)
/* Mixing C and C++ is ok, use C++ in that case. */
common_lang = highest_c_language (common_lang,
TRANSLATION_UNIT_LANGUAGE (t));
else
{
/* Fall back to C. */
common_lang = NULL;
break;
}
}
or maybe because the DW_TAG_imported_unit is too late? (I also see we have
duplicate imports at least with the patch).
Not sure what the correct representation is for abstract instances in a
C CU but the concrete instance being "inlined" out-of-line into a C++ CU.
