[Bug symtab/27922] New: [gdb/symtab] Don't create two dwarf2_cu's for the same CU

[Bug symtab/27922] New: [gdb/symtab] Don't create two dwarf2_cu's for the same CU

[vries at gcc dot gnu.org]

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

            Bug ID: 27922
           Summary: [gdb/symtab] Don't create two dwarf2_cu's for the same
                    CU
           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: ---

In PR27898, we run into a dwarf error, and the patch committed for the PR fixes
that dwarf error.

However, there is also an inefficiency: while create a dwarf2_cu for a specific
CU, we create yet another dwarf2_cu for the same CU.

This should be fixed.

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

[Bug symtab/27922] [gdb/symtab] Don't create two dwarf2_cu's for the same CU

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Let's try to investigate the size of the problem.

There are 17292 CUs:
...
$ readelf -wi --dwarf-depth 0 libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug |
grep -c "Compilation Unit @"
17292
...

Now let's instrument the partial DIE reader with some tracing:
...
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 4cc5b4f32d7..40531b7b804 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -18823,6 +18823,10 @@ load_partial_dies (const struct die_reader_specs
*reader,
   if (cu->load_all_dies)
     load_all = 1;

+  fprintf (stderr, "Loading%spartial DIEs for CU@%s\n",
+          load_all ? " all " : " ",
+          sect_offset_str (cu->header.sect_off));
+
   cu->partial_dies
     = htab_create_alloc_ex (cu->header.length / 12,
                            partial_die_hash,
...

Now do a run and set the max-cache-age such that nothing is evicted from the
cache (also double checked this with assert):
...
$ ./gdb.sh -q -batch -ex "maint set dwarf max-cache-age 100000" -ex
"symbol-file libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug" 2>&1 | tee LOG
...

So, we end up reading 50% more that the total number of CUs:
...
$ grep -c "Loading partial DIEs" LOG
26178
...
and as for loading all partial DIEs we have:
...
$ grep -c "Loading all partial DIEs" LOG 
781
...

For contrast, with "maint set dwarf max-cache-age 0" we have:
...
$ grep -c "Loading partial DIEs" LOG
37977
$ grep -c "Loading all partial DIEs" LOG
781
...

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

[Bug symtab/27922] [gdb/symtab] Don't create two dwarf2_cu's for the same CU

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

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

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
If this only affects partial DIEs, it can be closed now,
because those are gone and the new indexer takes a much
different approach -- it never caches DIEs.

It also should never read a given CU more than once.

If this problem affects full CUs, though, then the bug can remain open.

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

[Bug symtab/27922] [gdb/symtab] Don't create two dwarf2_cu's for the same CU

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.1
             Status|NEW                         |RESOLVED
         Resolution|---                         |OBSOLETE

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Tom Tromey from comment #2)
> If this only affects partial DIEs, it can be closed now,
> because those are gone and the new indexer takes a much
> different approach -- it never caches DIEs.

I re-read the bug & I think this is obsolete now.

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