[Bug gdb/25720] New: maint expand symtabs does not expand all partial symtabs

[Bug gdb/25720] New: maint expand symtabs does not expand all partial symtabs

[vries at gcc dot gnu.org]

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

            Bug ID: 25720
           Summary: maint expand symtabs does not expand all partial
                    symtabs
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

The command maint expand-symtabs is documented as:
...
maint expand-symtabs [regexp]

    Expand symbol tables. If regexp is specified, only expand symbol tables for
file names matching regexp.
...

I tried it on a hello world a.out:
...
$ gdb -batch a.out -ex "maint expand-symtabs" -ex "maint info psymtabs"
{ objfile /data/gdb_versions/devel/a.out ((struct objfile *) 0x2309ad0)
  { psymtab ../sysdeps/x86_64/crtn.S ((struct partial_symtab *) 0x2a9e6d0)
    readin no
    fullname (null)
    text addresses 0x400402 -- 0x40059d
    psymtabs_addrmap_supported yes
    globals (none)
    statics (none)
    dependencies (none)
  }
  { psymtab elf-init.c ((struct partial_symtab *) 0x2a842a0)
    readin yes
    fullname (null)
    text addresses 0x400520 -- 0x400592
    psymtabs_addrmap_supported yes
    globals (* (struct partial_symbol **) 0x2a4ca90 @ 2)
    statics (* (struct partial_symbol **) 0x2a84260 @ 7)
    dependencies (none)
  }
  { psymtab /home/vries/hello.c ((struct partial_symtab *) 0x2a393b0)
    readin yes
    fullname (null)
    text addresses 0x400507 -- 0x40051c
    psymtabs_addrmap_supported yes
    globals (* (struct partial_symbol **) 0x2a4ca88 @ 1)
    statics (* (struct partial_symbol **) 0x2a841e8 @ 15)
    dependencies (none)
  }
  { psymtab ../sysdeps/x86_64/crti.S ((struct partial_symtab *) 0x2a50640)
    readin no
    fullname (null)
    text addresses 0x4003f0 -- 0x400598
    psymtabs_addrmap_supported yes
    globals (none)
    statics (none)
    dependencies (none)
  }
  { psymtab init.c ((struct partial_symtab *) 0x2aa5a00)
    readin yes
    fullname (null)
    text addresses 0x0 -- 0x0
    psymtabs_addrmap_supported yes
    globals (* (struct partial_symbol **) 0x2a4ca80 @ 1)
    statics (* (struct partial_symbol **) 0x2a841a0 @ 9)
    dependencies (none)
  }
  { psymtab ../sysdeps/x86_64/start.S ((struct partial_symtab *) 0x2a70570)
    readin no
    fullname (null)
    text addresses 0x400430 -- 0x40045b
    psymtabs_addrmap_supported yes
    globals (none)
    statics (none)
    dependencies (none)
  }
}
...
and my expectation was that readin would be true for all psymtabs.

However, for these symtabs, that's not the case:
...
  { psymtab ../sysdeps/x86_64/crtn.S ((struct partial_symtab *) 0x2a9e6d0)
  { psymtab ../sysdeps/x86_64/crti.S ((struct partial_symtab *) 0x2a50640)
  { psymtab ../sysdeps/x86_64/start.S ((struct partial_symtab *) 0x2a70570)
...

Looking at the corresponding CUs in the readelf -wi output:
...
  Compilation Unit @ offset 0x0:
   Length:        0x2a (32-bit)
   Version:       2
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_stmt_list   : 0x0
    <10>   DW_AT_low_pc      : 0x400430
    <18>   DW_AT_high_pc     : 0x40045b
    <20>   DW_AT_name        : ../sysdeps/x86_64/start.S
    <24>   DW_AT_comp_dir    : /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
    <28>   DW_AT_producer    : GNU AS 2.31.1
    <2c>   DW_AT_language    : 32769    (MIPS assembler)
  Compilation Unit @ offset 0xa5:
   Length:        0x1e (32-bit)
   Version:       2
   Abbrev Offset: 0x52
   Pointer Size:  8
 <0><b0>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <b1>   DW_AT_stmt_list   : 0x85
    <b5>   DW_AT_ranges      : 0x0
    <b9>   DW_AT_name        : ../sysdeps/x86_64/crti.S
    <bd>   DW_AT_comp_dir    : /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
    <c1>   DW_AT_producer    : GNU AS 2.31.1
    <c5>   DW_AT_language    : 32769    (MIPS assembler)
  Compilation Unit @ offset 0x599:
   Length:        0x1e (32-bit)
   Version:       2
   Abbrev Offset: 0x25e
   Pointer Size:  8
 <0><5a4>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <5a5>   DW_AT_stmt_list   : 0x256
    <5a9>   DW_AT_ranges      : 0x40
    <5ad>   DW_AT_name        : ../sysdeps/x86_64/crtn.S
    <5b1>   DW_AT_comp_dir    : /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
    <5b5>   DW_AT_producer    : GNU AS 2.31.1
    <5b9>   DW_AT_language    : 32769   (MIPS assembler)
...
they're all single DIE CUs.

The explanation is that this test in psym_expand_symtabs_matching is failing:
...
          if (recursively_search_psymtabs (ps, objfile, domain,
...
which causes us to skip psymtab_to_symtab.

The search will match any symbol. But there are no symbols, so it fails.

When we load the exec using -readnow instead, we do end up with full symtabs
for these 3 files. So at the very least, that's inconsistent.

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

[Bug symtab/25720] maint expand symtabs does not expand all partial symtabs

[vries at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|gdb                         |symtab

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

[Bug symtab/25720] maint expand symtabs does not expand all partial symtabs

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
submitted patch:
https://sourceware.org/pipermail/gdb-patches/2020-March/167111.html

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

[Bug symtab/25720] maint expand symtabs does not expand all partial symtabs

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 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=c1a66c0629d3b62075a73793f1a7e7393e23e7e2

commit c1a66c0629d3b62075a73793f1a7e7393e23e7e2
Author: Tom de Vries <tdevries@suse.de>
Date:   Tue Apr 14 15:08:42 2020 +0200

    [gdb] Expand symbolless symtabs using maint expand-symtabs

    Consider this test-case, consisting of header file hello.h:
    ...
    inline static const char*
    foo (void)
    {
      return "foo";
    }
    ...
    and source file hello.c:
    ...
    int
    main (void)
    {
      printf ("hello: %s\n", foo ());
      return 0;
    }
    ...
    compiled with -g:
    ...
    $ gcc hello.c -g
    ...

    When trying to expand the partial symtab for hello.h:
    ...
    $ gdb -batch \
      -iex "set language c" \
      a.out \
      -ex "maint expand-symtabs hello.h" \
      -ex "maint info psymtabs"
    ...
    we in fact find that the partial symtab for hello.h (and corresponding
    includer partial symtab hello.c) have not been expanded:
    ...
      { psymtab hello.h ((struct partial_symtab *) 0x27cf070)
        readin no
      ...
      { psymtab hello.c ((struct partial_symtab *) 0x2cf09e0)
        readin no
    ...

    This is due to the recursively_search_psymtabs call in
    psym_expand_symtabs_matching:
    ...
          if (recursively_search_psymtabs (ps, objfile, domain,
                                          lookup_name, symbol_matcher))
    ...
    which always returns false for symbolless partial symtabs.

    The same problem occurs with CUs where the dwarf is generated by gas
    --gdwarf-2 for a foo.S: if we read such a test-case with -readnow, we'll
have
    a symbolless symtab for foo.S.  But if we read the test-case with partial
    symtabs, and expand those using "maint expand-symtabs", the foo.S psymtab
    remains unexpanded.

    Fix this by passing a NULL symbol_matcher and lookup_name to
    expand_symtabs_matching in maintenance_expand_symtabs, and skipping the
call
    to recursively_search_psymtabs if symbol_matcher == NULL and
    lookup_name == NULL.

    Build and tested on x86_64-linux, with native.

    In addition, tested test-case with target boards cc-with-gdb-index.exp,
    cc-with-debug-names.exp and readnow.exp.

    gdb/ChangeLog:

    2020-04-14  Tom de Vries  <tdevries@suse.de>

            PR symtab/25720
            * symmisc.c (maintenance_expand_symtabs): Call
expand_symtabs_matching
            with NULL symbol_matcher and lookup_name.
            * psymtab.c (psym_expand_symtabs_matching): Handle NULL
symbol_matcher
            and lookup_name.
            * dwarf2/read.c (dw2_expand_symtabs_matching)
            (dw2_debug_names_expand_symtabs_matching): Same.
            * symfile.h (struct
quick_symbol_functions::expand_symtabs_matching):
            Make lookup_name a pointer.  Update comment.
            * symtab.c (global_symbol_searcher::expand_symtabs): Handle
            lookup_name being a pointer.
            * symfile.c (expand_symtabs_matching): Same.
            * symfile-debug.c (debug_qf_expand_symtabs_matching): Same.
            * linespec.c (iterate_over_all_matching_symtabs): Same.

    gdb/testsuite/ChangeLog:

    2020-04-14  Tom de Vries  <tdevries@suse.de>

            PR symtab/25720
            * gdb.base/maint-expand-symbols-header-file.c: New test.
            * gdb.base/maint-expand-symbols-header-file.exp: New file.
            * gdb.base/maint-expand-symbols-header-file.h: New test.

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

[Bug symtab/25720] maint expand symtabs does not expand all partial symtabs

[vries at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

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

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