[Bug gdb/23712] New: dwarf2read.c:9730: internal-error: void dw2_add_symbol_to_list(symbol*, pending**): Assertion `(*listhead) == NULL || (SYMBOL_LANGUAGE ((*listhead)->symbol[0]) == SYMBOL_LANGUAGE (symbol))' failed

[rguenth at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23712

Bug ID: 23712
Summary: dwarf2read.c:9730: internal-error: void
dw2_add_symbol_to_list(symbol*, pending**): Assertion
`(*listhead) == NULL || (SYMBOL_LANGUAGE
((*listhead)->symbol[0]) == SYMBOL_LANGUAGE (symbol))'
failed
Product: gdb
Version: 8.2
Status: NEW
Severity: normal
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---

Created attachment 11273
--> https://sourceware.org/bugzilla/attachment.cgi?id=11273&action=edit
genchecksum binary (x86_64-linux)

gdb fails to process the gcc/build/genchecksum binary in a LTO bootrapped tree.
Note this is just one example (albeit a very small one).

gdb ../../obj3/gcc/build/genchecksum

GNU gdb (GDB; devel:gcc) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../../obj3/gcc/build/genchecksum...done.
../../gdb/dwarf2read.c:9730: internal-error: void
dw2_add_symbol_to_list(symbol*, pending**): Assertion `(*listhead) == NULL ||
(SYMBOL_LANGUAGE ((*listhead)->symbol[0]) == SYMBOL_LANGUAGE (symbol))' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)


The issue is that for the following the DW_TAG_variable and
DW_TAG_formal_parameter of the same abstract instance get associated different
symbol->ginfo.language. Here the context of 2599 is a C++ CU (generated by
LTO LTRANS) and the context of 2434 is a C CU (libiberty xstrerror.c). So
the concrete instance lives in the LTO LTRANS unit (togehter with genchecksum
functions which are from a C++ CU).

<1><2599>: Abbrev Number: 3 (DW_TAG_subprogram)
<259a> DW_AT_abstract_origin: <0x2434>
<259e> DW_AT_low_pc : 0x401300
<25a6> DW_AT_high_pc : 0x28
<25ae> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<25b0> DW_AT_GNU_all_call_sites: 1
<25b0> DW_AT_sibling : <0x2661>
<2><25b4>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<25b5> DW_AT_abstract_origin: <0x2440>
<25b9> DW_AT_location : 0xf35 (location list)
<25bd> DW_AT_GNU_locviews: 0xf2b
<2><25c1>: Abbrev Number: 5 (DW_TAG_variable)
<25c2> DW_AT_abstract_origin: <0x244c>
<25c6> DW_AT_location : 0xfae (location list)
<25ca> DW_AT_GNU_locviews: 0xfaa
<2><25ce>: Abbrev Number: 7 (DW_TAG_inlined_subroutine)
<25cf> DW_AT_abstract_origin: <0x2434>
<25d3> DW_AT_entry_pc : 0x401310
<25db> DW_AT_GNU_entry_view: 1
<25dd> DW_AT_low_pc : 0x401310
<25e5> DW_AT_high_pc : 0x16
<25ed> DW_AT_sibling : <0x264c>
<3><25f1>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<25f2> DW_AT_abstract_origin: <0x2440>
<25f6> DW_AT_location : 0xfef (location list)
<25fa> DW_AT_GNU_locviews: 0xfed
<3><25fe>: Abbrev Number: 8 (DW_TAG_lexical_block)
<25ff> DW_AT_low_pc : 0x401310
<2607> DW_AT_high_pc : 0x16
<4><260f>: Abbrev Number: 5 (DW_TAG_variable)
<2610> DW_AT_abstract_origin: <0x244c>
<2614> DW_AT_location : 0x1014 (location list)
<2618> DW_AT_GNU_locviews: 0x1012

[rguenth at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23712

Richard Biener <rguenth at gcc dot gnu.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |vries at gcc dot gnu.org

[rguenth at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23712

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
So I was experimenting and doing sth like

diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index 4a35e389e9..72d7962678 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -21328,7 +21328,11 @@ new_symbol (struct die_info *die, struct type *type,
struct dwarf2_cu *cu,
OBJSTAT (objfile, n_syms++);

/* Cache this symbol's name and the name's demangled form (if any). */
- SYMBOL_SET_LANGUAGE (sym, cu->language, &objfile->objfile_obstack);
+ dwarf2_cu *lang_cu = cu;
+ attribute *spec = dwarf2_attr (die, DW_AT_abstract_origin, cu);
+ if (spec)
+ follow_die_ref (die, spec, &lang_cu);
+ SYMBOL_SET_LANGUAGE (sym, lang_cu->language, &objfile->objfile_obstack);
linkagename = dwarf2_physname (name, die, cu);
SYMBOL_SET_NAMES (sym, linkagename, strlen (linkagename), 0, objfile);

gets us further, now running into

#1 0x000000000055d2db in insert_symbol_hashed (dict=0x142a0e0, sym=0x142a020)
at /space/rguenther/src/binutils-gdb/gdb/dictionary.c:690
690 gdb_assert (SYMBOL_LANGUAGE (sym) == DICT_LANGUAGE
(dict)->la_language);
(top-gdb) l
685 unsigned int hash;
686 struct symbol **buckets = DICT_HASHED_BUCKETS (dict);
687
688 /* We don't want to insert a symbol into a dictionary of a different
689 language. The two may not use the same hashing algorithm. */
690 gdb_assert (SYMBOL_LANGUAGE (sym) == DICT_LANGUAGE
(dict)->la_language);
691

for which there is a duplicate bugreport I think. The issue here seems to be
that we are doing

#3 0x00000000004b6eaa in buildsym_compunit::finish_block_internal (
this=0x13bc890, symbol=0x0, listhead=0x13bca10, old_blocks=0x0,
static_link=0x0, start=0x400bf0, end=0x4012cc, is_global=0, expandable=0)
at /space/rguenther/src/binutils-gdb/gdb/buildsym.c:245
245 m_language, *listhead);
(top-gdb) l
240 }
241 else
242 {
243 BLOCK_DICT (block) =
244 dict_create_hashed (&m_objfile->objfile_obstack,
245 m_language, *listhead);
246 }

with m_language == language_cplus but all symbols are language_c.

diff --git a/gdb/buildsym.c b/gdb/buildsym.c
index a9d2698584..ea0c9a537e 100644
--- a/gdb/buildsym.c
+++ b/gdb/buildsym.c
@@ -225,24 +225,27 @@ buildsym_compunit::finish_block_internal
? allocate_global_block (&m_objfile->objfile_obstack)
: allocate_block (&m_objfile->objfile_obstack));

+ language lang = m_language;
+ if (*listhead && (*listhead)->nsyms != 0)
+ lang = (*listhead)->symbol[0]->ginfo.language;
if (symbol)
{
BLOCK_DICT (block)
= dict_create_linear (&m_objfile->objfile_obstack,
- m_language, *listhead);
+ lang, *listhead);
}
else
{
if (expandable)
{
- BLOCK_DICT (block) = dict_create_hashed_expandable (m_language);
+ BLOCK_DICT (block) = dict_create_hashed_expandable (lang);
dict_add_pending (BLOCK_DICT (block), *listhead);
}
else
{
BLOCK_DICT (block) =
dict_create_hashed (&m_objfile->objfile_obstack,
- m_language, *listhead);
+ lang, *listhead);
}
}

"cures" that, just getting us back to the first assert ;)

[rguenth at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23712

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
This time with

(top-gdb) p symbol->ginfo
$1 = {name = 0x13cdfa0 "main(int, char**)", value = {ivalue = 0, block = 0x0,
bytes = 0x0, address = 0x0, common_block = 0x0, chain = 0x0},
language_specific = {obstack = 0x0, demangled_name = 0x0},
language = language_cplus, ada_mangled = 0, section = -1}
(top-gdb) p (*listhead)->symbol[0]->ginfo
$2 = {name = 0x13cdc80 "md5_process_block(void const*, size_t, md5_ctx*)",
value = {ivalue = 21143856, block = 0x142a130, bytes = 0x142a130 "\220\v@",
address = 0x142a130, common_block = 0x142a130, chain = 0x142a130},
language_specific = {obstack = 0x0, demangled_name = 0x0},
language = language_c, ada_mangled = 0, section = -1}

where the languages are correct.

I suppose gdb isn't really up to handling uses of different "language"
symbols in a single CU :/

What's the issue with that anyways? Why not simply _have_ different
language symbols in the symbol table?

[rguenth at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23712

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
For non-inline instances a solution on the GCC side might be to create separate
CUs matching the abstract instances CU but that wouldn't work for inline
instances nor for fixing 23713.

[rguenth at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23712

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Eventually the assert()s can be weakened to allow "compatible enough" (same
hash, etc.) languages? I realize that allowing LTO-like mixed language
environments looks like a very much larger change in gdb than I thought.

Though it looks like C and C++ use different symbol hashing... in fact all but
C++ seem to use default_search_name_hash ...

And what's the issue here? Just store the hash alongside the entries and then
the "only" issue is that gdb doesn't properly switch languages automatically
(PR23713) so user name lookups might fail spuriously.

[keiths at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23712

Keith Seitz <keiths at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |keiths at redhat dot com

--- Comment #5 from Keith Seitz <keiths at redhat dot com> ---
(In reply to Richard Biener from comment #4)

Post by rguenth at gcc dot gnu.org
Eventually the assert()s can be weakened to allow "compatible enough" (same
hash, etc.) languages? I realize that allowing LTO-like mixed language
environments looks like a very much larger change in gdb than I thought.
Though it looks like C and C++ use different symbol hashing... in fact all
but C++ seem to use default_search_name_hash ...
And what's the issue here? Just store the hash alongside the entries and
then
the "only" issue is that gdb doesn't properly switch languages automatically
(PR23713) so user name lookups might fail spuriously.

I just wanted to let you know that I am looking at fixing this once and
for all, but I am on vacation until next week. I have the (good) beginnings
of a patch for this.

Alas, there is a recent patch on HEAD that is causing problems for me
and will require further investigation.

[rguenth at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23712

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Keith Seitz from comment #5)

Post by keiths at redhat dot com
(In reply to Richard Biener from comment #4)

Post by rguenth at gcc dot gnu.org
Eventually the assert()s can be weakened to allow "compatible enough" (same
hash, etc.) languages? I realize that allowing LTO-like mixed language
environments looks like a very much larger change in gdb than I thought.
Though it looks like C and C++ use different symbol hashing... in fact all
but C++ seem to use default_search_name_hash ...
And what's the issue here? Just store the hash alongside the entries and
then
the "only" issue is that gdb doesn't properly switch languages automatically
(PR23713) so user name lookups might fail spuriously.

I just wanted to let you know that I am looking at fixing this once and
for all, but I am on vacation until next week. I have the (good) beginnings
of a patch for this.

That's great news!

[brobecker at gnat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23712

Joel Brobecker <brobecker at gnat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |brobecker at gnat dot com
Target Milestone|--- |8.2.1

--- Comment #7 from Joel Brobecker <brobecker at gnat dot com> ---
Mark this one as needed for 8.2.1 (see discussion on gdb-patches:
https://www.sourceware.org/ml/gdb-patches/2018-11/msg00096.html).

[rguenth at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23712

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, if GCC can do anything better here please speak up. Currently the CUs
generated at link-time (possibly combining different source language CUs) get
sth like

Compilation Unit @ offset 0x138:
Length: 0x8e (32-bit)
Version: 4
Abbrev Offset: 0xd2
Pointer Size: 8
<0><143>: Abbrev Number: 1 (DW_TAG_compile_unit)
<144> DW_AT_producer : (indirect string, offset: 0x22e): GNU GIMPLE
9.0.0 20181108 (experimental) -mtune=generic -march=x86-64 -mtune=generic
-march=x86-64 -g -fno-openmp -fno-openacc -fno-pie -fltrans
<148> DW_AT_language : 12 (ANSI C99)
<149> DW_AT_name : (indirect string, offset: 0x221): <artificial>
<14d> DW_AT_comp_dir : (indirect string, offset: 0x1ac):
/abuild/rguenther/obj-slpcost-g/gcc
<151> DW_AT_low_pc : 0x4004b2
<159> DW_AT_high_pc : 0x3c
<161> DW_AT_stmt_list : 0x10c

where DW_AT_language is either the single common language of the source CUs
contributing to this, the "newest" C/C++ when mixing C and C++ (where
C++ is "newer" than C), or as fallback DW_LANG_C (for example when combining
C and fortran). The standard says a CU entry _may_ have a DW_AT_language
attribute - would gdb be more happy when we do not emit any DW_AT_language
attribute for link-time generated DIEs? You can see we set a producer
of GNU GIMPLE which gdb may use to trigger special behavior (OTOH it
could do that whenever seeing a unit import with different DW_AT_language...)