[Bug mi/23042] typedef resolution traverses all CUs for MI var-create

[Bug mi/23042] typedef resolution traverses all CUs for MI var-create

[vries at gcc dot gnu.org]

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

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

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Martin Richtarsky from comment #1)
> Created attachment 10937 [details]
> Reproducer

The GOLD_PATH thing in the script doesn't work for me (and I'm not sure how
it's supposed to work).  I've managed to make it work using -fuse-ld=gold:
...
$ cat build.sh
#!/bin/sh

OPTS="-g -gdwarf-4 -gsplit-dwarf -g2 -ggdb "
LOPTS="-fuse-ld=gold -Wl,--gdb-index"
g++ -c sharedlib.cpp $OPTS -o sharedlib.o
g++ $LOPTS -shared sharedlib.o $OPTS -o libsharedlib.so
g++ -c main.cpp $OPTS -o main.o
g++ $LOPTS -o main $OPTS main.o -L. -lsharedlib
...

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

[Bug mi/23042] typedef resolution traverses all CUs for MI var-create

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
The .gdb_index shows for me these relevant entries:
...
CU table:
[  0] 0x0 - 0x2d     # glibc-2.26/sysdeps/x86_64/start.S
[  1] 0x2e - 0xa4    # glibc-2.26/csu/init.c
[  2] 0xa5 - 0xc6    # glibc-2.26/sysdeps/x86_64/crti.S
[  3] 0xc7 - 0xfa    # main.dwo
[  4] 0xfb - 0x2b2   # glibc-2.26/csu/elf-init.c
[  5] 0x2b3 - 0x2d4  # glibc-2.26/sysdeps/x86_64/crtn.S

Symbol table:

[114] size_t:
        3 [static, type]
        4 [global, no info]
[489] main: 3 [global, function]
[974] size_ttt: 3 [static, type]
...

Note that the info for size_t in CU 4 has "global, no info" because it's coming
from debug-info in an object file without
.debug_gnu_pubnames/.debug_gnu_pubtypes.

Setting a breakpoint in dw2_instantiate_symtab, I get expansion of:
- CU 3 at 0xc7 (main.dwo), because it contains main, which we need in
  set_initial_language
- CU 0 at 0x0 (start.S), because it contains an addresses in the range
  0x400550 - 0x40057b and 0x400579 is somehow required while getting the value
  of variable fast
- CU 4 at 0xfb (elf-init.c), because it contains size_t

Investigating the lookup of size_t in lookup_symbol_aux, it shows that what
eventually returns the symbol is the final fallback:
...
  /* Now search all static file-level symbols.  Not strictly correct,           
     but more useful than an error.  */

  result = lookup_static_symbol (name, domain);
...

The call to lookup_static_symbol returns the symbol from CU 4, but that is
coincidence.  When iterating over the expanded symtabs of an object file,
objfile->compunits is documented to be unordered, but it seems to be
last-added-first, so we first hit CU 4, which was added last.

When doing a "maint print symbols" after the two mi commands, I get four
expanded CUs containing a size_t typedef:
- main.cpp
- elf-init.c
- rtld.c (from /usr/lib/debug/lib64/ld-2.26.so-2.26-lp151.19.11.1.x86_64.debug)
- libc-start.c (from
/usr/lib/debug/lib64/libc-2.26.so-2.26-lp151.19.11.1.x86_64.debug)
but AFAICT, the expansions in the shared libs where not done while looking up
size_t.

So, I'm not sure I see something in this example that could cause things to be
unusuably slow.

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

[Bug mi/23042] typedef resolution traverses all CUs for MI var-create

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
My best guess is: if some of those shared libraries are build with gold
.gdb_index, but not with -ggnu-pubnames (implied by -gsplit-dwarf), you get
"[global, no info]" .gdb_index entries, also for size_t.

So, if a shared lib has 100 CUs, each defining size_t, and the .gdb_index has
"[global, no info]" entries for each of those, then when executing
dw2_lookup_symbol for size_t with block_index GLOBAL_BLOCK:
- the dw2_symtab_iter_next will return the CU for the first entry
- dw2_instantiate_symtab is called for that CU
- block_find_symbol is called, which fails because size_t is static, not global
- the dw2_symtab_iter_next will return the CU for the next entry
- and so on

The workaround for PR15646 is not activated in this case because !attrs_valid,
which is defined as:
...
      /* Only check the symbol attributes if they're present.                   
         Indices prior to version 7 don't record them,                          
         and indices >= 7 may elide them for certain symbols                    
         (gold does this).  */
      int attrs_valid =
        (dwarf2_per_objfile->per_bfd->index_table->version >= 7
         && symbol_kind != GDB_INDEX_SYMBOL_KIND_NONE);
...

I'm currently preparing a patch to limit the scope of the workaround to
symbol_kind == GDB_INDEX_SYMBOL_KIND_TYPE, because in some cases we do want
symbol lookup to find multiple version of a symbol.

Extending the workaround to GDB_INDEX_SYMBOL_KIND_NONE would break that (and
other things as well, I guess, given that we cannot tell global and static
apart).

We could try harder in dw2_lookup_symbol, by iterating twice, first using all
but GDB_INDEX_SYMBOL_KIND_NONE symbols, and then the GDB_INDEX_SYMBOL_KIND_NONE
ones. But that wouldn't help for this case.

We could do a scan of a .gdb_index, find all untyped entries, and revert back
to  partial symbols for those ones.

With a less fine granularity, we could do a scan of a .gdb_index, and upon
finding one untyped entry, revert to partial symbols for the whole objfile. 
But as comment 4 shows, that would make gold --gdb-index unusable on my system,
unless I modify the glibc package to build elf-init.c using -ggnu-pubnames.

That fastest solution obviously would be to make sure that gold -gdb-index is
always paired with -ggnu-pubnames.

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