[Bug gdb/25646] New: Inconsistency for partial symbols with imported units

[Bug gdb/25646] New: Inconsistency for partial symbols with imported units

[vries at gcc dot gnu.org]

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

            Bug ID: 25646
           Summary: Inconsistency for partial symbols with imported units
           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: ---

Consider hello.c:
...
#include <stdio.h>

int
main (void)
{
  printf ("hello\n");
  return 0;
}
...

Compiled with debug info:
...
$ gcc -g hello.c
...

And a.out dwz-compressed:
...
$ dwz a.out -o a.out.dwz --devel-ignore-size
...

When we print the partial symbols:
...
$ gdb -batch -iex "set language c"  a.out.dwz -ex "maint print psymbols"
...

We see a psymtab corresponding to the partial unit at 0xb, with 4 types:
...
Partial symtab for source file  (object 0x23b08e0)

  Read from object file /home/vries/lldb/a.out.dwz (0x23875f0)
  Symbols cover text addresses 0x0-0x0
  Address map supported - yes.
  Depends on 0 other partial symtabs.
  Shared partial symtab with user 0x23d0340
  Static partial symbols:
    `long unsigned int', type, 0x0
    `int', type, 0x0
    `long int', type, 0x0
    `char', type, 0x0
...

and a psymtab corresponding to the partial unit at 0x3c, with 5 types:
...
Partial symtab for source file  (object 0x23f03b0)

  Read from object file /home/vries/lldb/a.out.dwz (0x23875f0)
  Symbols cover text addresses 0x0-0x0
  Address map supported - yes.
  Depends on 0 other partial symtabs.
  Shared partial symtab with user 0x23d0340
  Static partial symbols:
    `unsigned char', type, 0x0
    `short unsigned int', type, 0x0
    `unsigned int', type, 0x0
    `signed char', type, 0x0
    `short int', type, 0x0
...

Then, there's a partial unit that imports both those partial units:
...
  <0><9a>: Abbrev Number: 44 (DW_TAG_partial_unit)
 <1><9b>: Abbrev Number: 5 (DW_TAG_imported_unit)
    <9c>   DW_AT_import      : <0xb>    [Abbrev Number: 42]
 <1><a0>: Abbrev Number: 5 (DW_TAG_imported_unit)
    <a1>   DW_AT_import      : <0x3c>   [Abbrev Number: 42]
...
and the corresponding psymtab shows all the symbols of the imported partial
units, as well as the corresponding dependencies:
...
Partial symtab for source file  (object 0x23d0340)

  Read from object file /home/vries/lldb/a.out.dwz (0x23875f0)
  Symbols cover text addresses 0x0-0x0
  Address map supported - yes.
  Depends on 2 other partial symtabs.
    0 0x23b08e0
    1 0x23f03b0
  Shared partial symtab with user 0x23c36b0
  Static partial symbols:
    `long unsigned int', type, 0x0
    `int', type, 0x0
    `long int', type, 0x0
    `char', type, 0x0
    `unsigned char', type, 0x0
    `short unsigned int', type, 0x0
    `unsigned int', type, 0x0
    `signed char', type, 0x0
    `short int', type, 0x0
...

However, a subsequent compilation unit also imports partial unit 0xb:
...
 <0><3b9>: Abbrev Number: 16 (DW_TAG_compile_unit)
 <1><3d4>: Abbrev Number: 5 (DW_TAG_imported_unit)
    <3d5>   DW_AT_import      : <0xb>   [Abbrev Number: 42]
...
but the corresponding psymtab does not contain the types from the imported
partial unit (though it does contain the corresponding dependency):
...
Partial symtab for source file elf-init.c (object 0x23ac7c0)

  Read from object file /home/vries/lldb/a.out.dwz (0x23875f0)
  Symbols cover text addresses 0x400520-0x400592
  Address map supported - yes.
  Depends on 2 other partial symtabs.
    0 0x23b08e0
    1 0x23f0330
  Global partial symbols:
    `__libc_csu_fini', function, 0x400590
    `__libc_csu_init', function, 0x400520
  Static partial symbols:
    `long long int', type, 0x0
    `long double', type, 0x0
...

AFAICT, this is an artefact from the fact that all CUs in an objfile share the
same storage array for static partial symbols, using a range to describe their
symbols.

Then when scanning the partial symbols of a CU and encountering an import,
either:
- the referred CU has not been parsed yet, and will be parsed, and the range of
  static partial symbols of the referred CU will be a subrange of the range of
  static partial symbols of this CU, or
- the referred CU has already been parsed, and the range of static partial
  symbols of the referred CU will not be a subrange of the range of static
  partial symbols of this CU.

I'm not sure if this is intended behaviour, that is, I didn't find a comment
explaining this as an opportunistic optimization.

OTOH, I'm not sure if this causes problems. I can imagine this perhaps causes
expansion into full symtabs for more partial symtabs than necessary, but I
don't understand the process well enough yet to know whether that will happen.

Also, I think this might cause us to iterate over these partial symbols twice
when doing a lookup, once in the including partial unit, and once when
following dependencies.

Either way, atm if you want to use the output of "maint print psymbols" to
understand in which psymtab a symbol is defined, this quirk does not help.

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

[Bug gdb/25646] Inconsistency for partial symbols with imported units

[vries at gcc dot gnu.org]

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

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

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

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

[Bug gdb/25646] Inconsistency for partial symbols with imported units

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Hmm, this probably happens with global_psymbols as well, which is sorted.

So, when sorting the outer CU global_psymbols, we may be moving symbols in and
out of the range of the inner CUs.

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

[Bug gdb/25646] Inconsistency for partial symbols with imported units

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 12364
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12364&action=edit
Tentative patch

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

[Bug symtab/25646] Inconsistency for partial symbols with imported units

[vries at gcc dot gnu.org]

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

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/25646] Inconsistency for partial symbols with imported units

[vries at gcc dot gnu.org]

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

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

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

[Bug symtab/25646] Inconsistency for partial symbols with imported units

[vries at gcc dot gnu.org]

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

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

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
patch with test-case committed (
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=96c7f873945c31bb0f9facd526bfe6dac74d3ccb
).

Marking resolved-fixed.

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