[Bug symtab/27898] New: [gdb] Cannot not find DIE

[Bug symtab/27898] New: [gdb] Cannot not find DIE

[vries at gcc dot gnu.org]

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

            Bug ID: 27898
           Summary: [gdb] Cannot not find DIE
           Product: gdb
           Version: 10.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ As reported here (
https://sourceware.org/pipermail/gdb-patches/2021-May/179087.html ). ]

When loading the debug info package
libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug from openSUSE Leap 15.2, we run
into:
...
$ gdb -q -batch -ex run --args /usr/bin/lli test.ll
Dwarf Error: Cannot not find DIE at 0x18a936e7 \
  [from module libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug]
...

The error doesn't occur with -readnow.

Looking at the dwarf, it seems valid:
...
  Compilation Unit @ offset 0x18a23e52:
  ...
 <0><18a23e5d>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <18a23e5e>   DW_AT_producer    : clang version 10.0.1
/home/abuild/rpmbuild/BUILD/llvm-10.0.1.src/stage1/bin/clang-10
--driver-mode=g++ -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D
__STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -I lib/ExecutionEngine/Orc
-I ../lib/ExecutionEngine/Orc -I /usr/include/libxml2 -I include -I
../include -fmessage-length=0 -grecord-command-line -O2 -Wall -D
_FORTIFY_SOURCE=0 -fstack-protector-strong -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -D NDEBUG -fPIC
-fvisibility-inlines-hidden -Wall -Wextra -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
-Wno-long-long -Wimplicit-fallthrough -Wno-noexcept-type
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion
-fdiagnostics-color -ffunction-sections -fdata-sections -flto=thin -O2
-g -D NDEBUG -fno-exceptions -std=c++14 -MD -MT
lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o -MF
lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o.d -o
lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o -c
../lib/ExecutionEngine/Orc/LLJIT.cpp
    <18a23e62>   DW_AT_language    : 33 (C++14)
    <18a23e64>   DW_AT_name        : ../lib/ExecutionEngine/Orc/LLJIT.cpp
 ...
 <1><18a936d4>: Abbrev Number: 71 (DW_TAG_subprogram)
 <2><18a936d5>: Abbrev Number: 174 (DW_TAG_class_type)
    <18a936d7>   DW_AT_calling_convention: 5    (pass by value)
    <18a936d8>   DW_AT_byte_size   : 8
    <18a936d9>   DW_AT_decl_file   : 185
    <18a936da>   DW_AT_decl_line   : 78
 <3><18a936db>: Abbrev Number: 9 (DW_TAG_member)
    <18a936dc>   DW_AT_name        : this
    <18a936e0>   DW_AT_type        : <0x18a8bb20>
    <18a936e4>   DW_AT_decl_file   : 185
    <18a936e5>   DW_AT_decl_line   : 78
    <18a936e6>   DW_AT_data_member_location: 0
 <3><18a936e7>: Abbrev Number: 175 (DW_TAG_subprogram)
    <18a936e9>   DW_AT_name        : operator()
    <18a936ed>   DW_AT_decl_file   : 185
    <18a936ee>   DW_AT_decl_line   : 78
    <18a936ef>   DW_AT_type        : <0x18a557ad>
    <18a936f3>   DW_AT_declaration : 1
    <18a936f3>   DW_AT_external    : 1
    <18a936f3>   DW_AT_accessibility: 1 (public)

  ...

 <1><18aa3589>: Abbrev Number: 251 (DW_TAG_subprogram)
    <18aa358b>   DW_AT_linkage_name: _ZZN4llvm10ThreadPool4waitEvENK3$_1clEv
    <18aa358f>   DW_AT_specification: <0x18a936e7>
    <18aa3593>   DW_AT_inline      : 1  (inlined)
    <18aa3594>   DW_AT_object_pointer: <0x18aa3598>
  ...
  Compilation Unit @ offset 0x18aa33d6:
...

I would be nice to get a smaller reproducer:
...
$ du -h /usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug
1.3G    /usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/27898] [gdb] Cannot not find DIE

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Backtrace at error:
...
Thread 1 "gdb" hit Breakpoint 1, error (
    fmt=0xef3538 "Dwarf Error: Cannot not find DIE at %s [from module %s]\n")
    at /home/vries/gdb_versions/devel/src/gdbsupport/errors.cc:42
42        va_start (ap, fmt);
(gdb) bt
#0  error (fmt=0xef3538 "Dwarf Error: Cannot not find DIE at %s [from module
%s]\n")
    at /home/vries/gdb_versions/devel/src/gdbsupport/errors.cc:42
#1  0x00000000006a3ea6 in find_partial_die (sect_off=(unknown: 0x18a936e7),
offset_in_dwz=0, 
    cu=0x96523d0) at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:19418
#2  0x00000000006a4111 in partial_die_info::fixup (this=0x6696ab0,
cu=0xa4faaf0)
    at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:19512
#3  0x0000000000685a33 in scan_partial_symbols (first_die=0x6696570,
lowpc=0x7fffffffcee8, 
    highpc=0x7fffffffcee0, set_addrmap=1, cu=0xa4faaf0)
    at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:7563
#4  0x0000000000683e35 in process_psymtab_comp_unit_reader
(reader=0x7fffffffcfd0, 
    info_ptr=0x7fffc1bbe814
"\215\001\363\371\"\004\203\002\002GTP\245\030\001\062", 
    comp_unit_die=0x6696290, pretend_language=language_minimal)
    at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:6954
#5  0x00000000006842b4 in process_psymtab_comp_unit (this_cu=0x240bc30, 
    per_objfile=0x1b1b1d0, want_partial_unit=false,
pretend_language=language_minimal)
    at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:7057
#6  0x000000000068519e in dwarf2_build_psymtabs_hard (per_objfile=0x1b1b1d0)
    at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:7399
#7  0x0000000000680698 in dwarf2_build_psymtabs (objfile=0x1b19fa0,
psf=0x1a1b4f0)
    at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:5550
#8  0x00000000006b80d8 in lazy_dwarf_reader::read_partial_symbols
(this=0x1a1b4f0, 
    objfile=0x1b19fa0) at
/home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:2016
#9  0x0000000000a54dc3 in objfile::require_partial_symbols (this=0x1b19fa0,
verbose=false)
    at /home/vries/gdb_versions/devel/src/gdb/symfile-debug.c:513
#10 0x0000000000a58331 in read_symbols (objfile=0x1b19fa0, add_flags=...)
    at /home/vries/gdb_versions/devel/src/gdb/symfile.c:794
#11 0x0000000000a58839 in syms_from_objfile_1 (objfile=0x1b19fa0,
addrs=0x7fffffffd2e0, 
    add_flags=...) at /home/vries/gdb_versions/devel/src/gdb/symfile.c:967
#12 0x0000000000a588fd in syms_from_objfile (objfile=0x1b19fa0, addrs=0x0,
add_flags=...)
    at /home/vries/gdb_versions/devel/src/gdb/symfile.c:984
#13 0x0000000000a58dca in symbol_file_add_with_addrs (abfd=0x1996e50, 
    name=0x7fffffffe12c
"/usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug",
add_flags=..., addrs=0x0, flags=..., parent=0x0)
    at /home/vries/gdb_versions/devel/src/gdb/symfile.c:1087
#14 0x0000000000a59126 in symbol_file_add_from_bfd (abfd=0x1996e50, 
    name=0x7fffffffe12c
"/usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug",
add_flags=..., addrs=0x0, flags=..., parent=0x0)
    at /home/vries/gdb_versions/devel/src/gdb/symfile.c:1167
#15 0x0000000000a59180 in symbol_file_add (
    name=0x7fffffffe12c
"/usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug",
add_flags=..., addrs=0x0, flags=...)
    at /home/vries/gdb_versions/devel/src/gdb/symfile.c:1180
--Type <RET> for more, q to quit, c to continue without paging--
#16 0x0000000000a59245 in symbol_file_add_main_1 (
    args=0x7fffffffe12c
"/usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug",
add_flags=..., flags=..., reloff=0)
    at /home/vries/gdb_versions/devel/src/gdb/symfile.c:1204
#17 0x0000000000a591ec in symbol_file_add_main (
    args=0x7fffffffe12c
"/usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug",
add_flags=...) at /home/vries/gdb_versions/devel/src/gdb/symfile.c:1195
#18 0x0000000000829537 in symbol_file_add_main_adapter (
    arg=0x7fffffffe12c
"/usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug",
from_tty=0) at /home/vries/gdb_versions/devel/src/gdb/main.c:550
#19 0x0000000000829481 in catch_command_errors (
    command=0x8294e8 <symbol_file_add_main_adapter(char const*, int)>, 
    arg=0x7fffffffe12c
"/usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug",
from_tty=0, do_bp_actions=false) at
/home/vries/gdb_versions/devel/src/gdb/main.c:523
#20 0x000000000082a62e in captured_main_1 (context=0x7fffffffd9c0)
    at /home/vries/gdb_versions/devel/src/gdb/main.c:1236
#21 0x000000000082abdf in captured_main (data=0x7fffffffd9c0)
    at /home/vries/gdb_versions/devel/src/gdb/main.c:1343
#22 0x000000000082ac4a in gdb_main (args=0x7fffffffd9c0)
    at /home/vries/gdb_versions/devel/src/gdb/main.c:1368
#23 0x00000000004178dd in main (argc=14, argv=0x7fffffffdac8)
    at /home/vries/gdb_versions/devel/src/gdb/gdb.c:32
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/27898] [gdb] Cannot not find DIE

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
I managed to track execution to the point where the pdi is created:
...
(gdb) p find_partial_die ((sect_offset)0x18a936e7, 0, cu)
$20 = {cu = 0x984b320, pdi = 0x8c8b650}
(gdb) p $20.pdi
$21 = (partial_die_info *) 0x8c8b650
(gdb) p *$20.pdi
$22 = {<allocate_on_obstack> = {<No data fields>}, sect_off = (unknown:
0x18a936e7), 
  tag = DW_TAG_subprogram, has_children = 1, is_external = 1, is_declaration =
1, 
  has_type = 1, has_specification = 0, has_pc_info = 0, may_be_inlined = 0, 
  main_subprogram = 0, scope_set = 0, has_byte_size = 0, has_const_value = 0, 
  has_template_arguments = 0, fixup_called = 0, is_dwz = 0, spec_is_dwz = 0, 
  canonical_name = 0, raw_name = 0x7fffa342e929 "operator()", linkage_name =
0x0, 
  scope = 0x0, d = {locdesc = 0x0, sect_off = 0}, lowpc = 0, highpc = 0,
sibling = 0x0, 
  spec_offset = 0, die_parent = 0x8c8b570, die_child = 0x0, die_sibling = 0x0}
...
and successfully execute the find_partial_die call that later on fails.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/27898] [gdb] Cannot not find DIE

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> Dwarf Error: Cannot not find DIE at 0x18a936e7 \

Hmm, it seems the double negation is mine...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/27898] [gdb] Cannot not find DIE

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Doesn't fail at gdb 9.2.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/27898] [gdb] Cannot not find DIE

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #5 from Simon Marchi <simark at simark dot ca> ---
For us non-OpenSuse users, I managed to reproduce by downloading and extracting
these files:

http://download.opensuse.org/repositories/devel:/tools:/compiler/openSUSE_Leap_15.2/x86_64/libLLVM10-10.0.1-lp152.30.5.x86_64.rpm
http://download.opensuse.org/repositories/devel:/tools:/compiler/openSUSE_Leap_15.2/x86_64/libLLVM10-debuginfo-10.0.1-lp152.30.5.x86_64.rpm

$ ./gdb -nx --data-directory=data-directory -q
/home/simark/Downloads/llvm/usr/lib64/libLLVM.so.10 -iex "set
debug-file-directory /home/simark/Downloads/llvm/usr/lib/debug" 
Reading symbols from /home/simark/Downloads/llvm/usr/lib64/libLLVM.so.10...
Reading symbols from
/home/simark/Downloads/llvm/usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.5.x86_64.debug...
Dwarf Error: Cannot not find DIE at 0x18a936e7 [from module
/home/simark/Downloads/llvm/usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.5.x86_64.debug]

(No debugging symbols found in
/home/simark/Downloads/llvm/usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.5.x86_64.debug)
(gdb)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/27898] [gdb] Cannot not find DIE

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #4)
> Doesn't fail at gdb 9.2.

Bisects to:
...
f9b5d5ea18a3878ca48c1b747e35d456133858bc is the first bad commit
commit f9b5d5ea18a3878ca48c1b747e35d456133858bc
Author: Tom de Vries <tdevries@suse.de>
Date:   Wed Jun 3 23:50:16 2020 +0200

    [gdb/symtab] Fix missing breakpoint location for inlined function
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/27898] [gdb] Cannot not find DIE

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
Hmm, so the sequence of events is as follows:
- we create a dwarf2_cu
- we create another dwarf2_cu for the same per_cu
- the second dwarf2_cu is set in per_objfile->m_dwarf2_cus.
- per_cu->load_all_dies is set to 1
- all dies are read into the partial_dies htab for the first dwarf2_cu
- the first dwarf2_cu is destroyed
- we try to find a partial_die in the partial_dies htab for the second
  dwarf2_cu.  We can't find it, but do not try to load all dies, because
  per_cu->load_all_dies is already set
- an error message is generated.

There is some code to prevent creating a second dwarf2_cu:
...
      cu = per_objfile->get_cu (per_cu);
      if (cu == NULL || cu->partial_dies == NULL)
        load_partial_comp_unit (per_cu, per_objfile, nullptr);
...
But get_cu only delivers a results after reader.keep() is done.  In this case,
the reader is still live, so it returns NULL.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/27898] [gdb] Cannot not find DIE

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
This fixes it:
...
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 2cd8a95658a..c20fe795256 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -7054,9 +7054,13 @@ process_psymtab_comp_unit (dwarf2_per_cu_data *this_cu,
                                reader.comp_unit_die);
   else if (want_partial_unit
           || reader.comp_unit_die->tag != DW_TAG_partial_unit)
-    process_psymtab_comp_unit_reader (&reader, reader.info_ptr,
-                                     reader.comp_unit_die,
-                                     pretend_language);
+    {
+      if (reader.comp_unit_die->tag != DW_TAG_partial_unit)
+       reader.keep ();
+      process_psymtab_comp_unit_reader (&reader, reader.info_ptr,
+                                       reader.comp_unit_die,
+                                       pretend_language);
+    }

   this_cu->lang = reader.cu->language;

...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/27898] [gdb] Cannot not find DIE

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|10.1                        |HEAD

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/27898] [gdb] Cannot not find DIE

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #8)
> This fixes it:

But causes many regression.

This also fixes it, now testing:
...
$ git diff
diff --git a/gdb/dwarf2/cu.c b/gdb/dwarf2/cu.c
index 2451df4f5b6..1031ed3aa00 100644
--- a/gdb/dwarf2/cu.c
+++ b/gdb/dwarf2/cu.c
@@ -35,7 +35,8 @@ dwarf2_cu::dwarf2_cu (dwarf2_per_cu_data *per_cu,
     producer_is_icc (false),
     producer_is_icc_lt_14 (false),
     producer_is_codewarrior (false),
-    processing_has_namespace_info (false)
+    processing_has_namespace_info (false),
+    load_all_dies (false)
 {
 }

diff --git a/gdb/dwarf2/cu.h b/gdb/dwarf2/cu.h
index ff56ec5527b..65a4cf8babf 100644
--- a/gdb/dwarf2/cu.h
+++ b/gdb/dwarf2/cu.h
@@ -283,6 +283,12 @@ struct dwarf2_cu

     return nullptr;
   }
+
+  /* This flag will be set when reading partial DIEs if we need to load
+     absolutely all DIEs for this compilation unit, instead of just the ones
+     we think are interesting.  It gets set if we look for a DIE in the
+     hash table and don't find it.  */
+  unsigned int load_all_dies : 1;
 };

 #endif /* GDB_DWARF2_CU_H */
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 2cd8a95658a..c23a8b99360 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -18831,7 +18831,7 @@ load_partial_dies (const struct die_reader_specs
*reader,
   last_die = NULL;

   gdb_assert (cu->per_cu != NULL);
-  if (cu->per_cu->load_all_dies)
+  if (cu->load_all_dies)
     load_all = 1;

   cu->partial_dies
@@ -19399,9 +19399,9 @@ find_partial_die (sect_offset sect_off, int
offset_in_dwz, str
uct dwarf2_cu *cu)
   /* If we didn't find it, and not all dies have been loaded,
      load them all and try again.  */

-  if (pd == NULL && cu->per_cu->load_all_dies == 0)
+  if (pd == NULL && cu->load_all_dies == 0)
     {
-      cu->per_cu->load_all_dies = 1;
+      cu->load_all_dies = 1;

       /* This is nasty.  When we reread the DIEs, somewhere up the call chain
         THIS_CU->cu may already be in use.  So we can't just free it and
diff --git a/gdb/dwarf2/read.h b/gdb/dwarf2/read.h
index 6af1f44bd47..0bb3da5a34a 100644
--- a/gdb/dwarf2/read.h
+++ b/gdb/dwarf2/read.h
@@ -421,7 +421,6 @@ struct dwarf2_per_cu_data
 {
   dwarf2_per_cu_data ()
     : queued (false),
-      load_all_dies (false),
       is_debug_types (false),
       is_dwz (false),
       reading_dwo_directly (false),
@@ -447,12 +446,6 @@ struct dwarf2_per_cu_data
      any of the current compilation units are processed.  */
   unsigned int queued : 1;

-  /* This flag will be set when reading partial DIEs if we need to load
-     absolutely all DIEs for this compilation unit, instead of just the ones
-     we think are interesting.  It gets set if we look for a DIE in the
-     hash table and don't find it.  */
-  unsigned int load_all_dies : 1;
-
   /* Non-zero if this CU is from .debug_types.
      Struct dwarf2_per_cu_data is contained in struct signatured_type iff
      this is non-zero.  */
...

Basically, moving load_all_dies from dwarf2_per_cu_data to dwarf2_cu.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/27898] [gdb] Cannot not find DIE

[vries at gcc dot gnu.org]

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

--- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
https://sourceware.org/pipermail/gdb-patches/2021-May/179246.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/27898] [gdb] Cannot not find DIE

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6dcd1193d978ac48fa566815dd949e264cd6bc37

commit 6dcd1193d978ac48fa566815dd949e264cd6bc37
Author: Tom de Vries <tdevries@suse.de>
Date:   Thu May 27 15:22:38 2021 +0200

    [gdb/symtab] Fix Dwarf Error: cannot find DIE

    When loading the debug info package
    libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug from openSUSE Leap 15.2, we
    run into a dwarf error:
    ...
    $ gdb -q -batch libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug
    Dwarf Error: Cannot not find DIE at 0x18a936e7 \
      [from module libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug]
    ...
    The DIE @ 0x18a936e7 does in fact exist, and is part of a CU @ 0x18a23e52.
    No error message is printed when using -readnow.

    What happens is the following:
    - a dwarf2_per_cu_data P is created for the CU.
    - a dwarf2_cu A is created for the same CU.
    - another dwarf2_cu B is created for the same CU.
    - the dwarf2_cu B is set in per_objfile->m_dwarf2_cus, such that
      per_objfile->get_cu (P) returns B.
    - P->load_all_dies is set to 1.
    - all dies are read into the A->partial_dies htab
    - dwarf2_cu A is destroyed.
    - we try to find the partial_die for the DIE @ 0x18a936e7 in
B->partial_dies.
      We can't find it, but do not try to load all dies, because
P->load_all_dies
      is already set to 1.
    - an error message is generated.

    The question is why we're creating dwarf2_cu A and B for the same CU.

    The dwarf2_cu A is created here:
    ...
     (gdb) bt
     #0  dwarf2_cu::dwarf2_cu (this=0x79a9660, per_cu=0x23c0b30,
         per_objfile=0x1ad01b0) at dwarf2/cu.c:38
     #1  0x0000000000675799 in cutu_reader::cutu_reader (this=0x7fffffffd040,
         this_cu=0x23c0b30, per_objfile=0x1ad01b0, abbrev_table=0x0,
         existing_cu=0x0, skip_partial=false) at dwarf2/read.c:6487
     #2  0x0000000000676eb3 in process_psymtab_comp_unit (this_cu=0x23c0b30,
          per_objfile=0x1ad01b0, want_partial_unit=false,
          pretend_language=language_minimal) at dwarf2/read.c:7028
    ...

    And the dwarf2_cu B is created here:
    ...
     (gdb) bt
     #0  dwarf2_cu::dwarf2_cu (this=0x885e8c0, per_cu=0x23c0b30,
         per_objfile=0x1ad01b0) at dwarf2/cu.c:38
     #1  0x0000000000675799 in cutu_reader::cutu_reader (this=0x7fffffffcc50,
         this_cu=0x23c0b30, per_objfile=0x1ad01b0, abbrev_table=0x0,
         existing_cu=0x0, skip_partial=false) at dwarf2/read.c:6487
     #2  0x0000000000678118 in load_partial_comp_unit (this_cu=0x23c0b30,
         per_objfile=0x1ad01b0, existing_cu=0x0) at dwarf2/read.c:7436
     #3  0x000000000069721d in find_partial_die (sect_off=(unknown:
0x18a55054),
         offset_in_dwz=0, cu=0x0) at dwarf2/read.c:19391
     #4  0x000000000069755b in partial_die_info::fixup (this=0x9096900,
         cu=0xa6a85f0) at dwarf2/read.c:19512
     #5  0x0000000000697586 in partial_die_info::fixup (this=0x8629bb0,
         cu=0xa6a85f0) at dwarf2/read.c:19516
     #6  0x00000000006787b1 in scan_partial_symbols (first_die=0x8629b40,
         lowpc=0x7fffffffcf58, highpc=0x7fffffffcf50, set_addrmap=0,
cu=0x79a9660)
         at dwarf2/read.c:7563
     #7  0x0000000000678878 in scan_partial_symbols (first_die=0x796ebf0,
         lowpc=0x7fffffffcf58, highpc=0x7fffffffcf50, set_addrmap=0,
cu=0x79a9660)
         at dwarf2/read.c:7580
     #8  0x0000000000676b82 in process_psymtab_comp_unit_reader
         (reader=0x7fffffffd040, info_ptr=0x7fffc1b3f29b,
comp_unit_die=0x6ea90f0,
         pretend_language=language_minimal) at dwarf2/read.c:6954
     #9  0x0000000000676ffd in process_psymtab_comp_unit (this_cu=0x23c0b30,
         per_objfile=0x1ad01b0, want_partial_unit=false,
         pretend_language=language_minimal) at dwarf2/read.c:7057
    ...

    So in frame #9, a cutu_reader is created with dwarf2_cu A.  Then a fixup
takes
    us to the following CU @ 0x18aa33d6, in frame #5.  And a similar fixup in
    frame #4 takes us back to CU @ 0x18a23e52.  At that point, there's no
    information available that we're already trying to read that CU, and we end
up
    creating another cutu_reader with dwarf2_cu B.

    It seems that there are two related problems:
    - creating two dwarf2_cu's is not optimal
    - the unoptimal case is not handled correctly

    This patch addresses the last problem, by moving the load_all_dies flag
from
    dwarf2_per_cu_data to dwarf2_cu, such that it is paired with the
partial_dies
    field, which ensures that the two can be kept in sync.

    Tested on x86_64-linux.

    gdb/ChangeLog:

    2021-05-27  Tom de Vries  <tdevries@suse.de>

            PR symtab/27898
            * dwarf2/cu.c (dwarf2_cu::dwarf2_cu): Add load_all_dies init.
            * dwarf2/cu.h (dwarf2_cu): Add load_all_dies field.
            * dwarf2/read.c (load_partial_dies, find_partial_die): Update.
            * dwarf2/read.h (dwarf2_per_cu_data::dwarf2_per_cu_data): Remove
            load_all_dies init.
            (dwarf2_per_cu_data): Remove load_all_dies field.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/27898] [gdb] Cannot not find DIE

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |11.1

--- Comment #12 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch committed, marking resolved-fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/27898] [gdb] Cannot not find DIE

[vries at gcc dot gnu.org]

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

--- Comment #13 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to cvs-commit@gcc.gnu.org from comment #11)
>     It seems that there are two related problems:
>     - creating two dwarf2_cu's is not optimal

Filed PR27922 - "[gdb/symtab] Don't create two dwarf2_cu's for the same CU"

-- 
You are receiving this mail because:
You are on the CC list for the bug.