[Bug symtab/25771] New: Inter-cu DW_AT_abstract_origin results in wrong file

[Bug symtab/25771] New: Inter-cu DW_AT_abstract_origin results in wrong file

[vries at gcc dot gnu.org]

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

            Bug ID: 25771
           Summary: Inter-cu DW_AT_abstract_origin results in wrong file
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider test-case gdb.ada/call_pn.exp, run with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects.

When trying to print last_node_id, we get:
...
$ gdb foo -ex "print last_node_id"
Multiple matches for last_node_id
[0] cancel
[1] pck.last_node_id at src/gdb/testsuite/gdb.ada/call_pn/pck.adb:17
[2] pck.last_node_id at src/gdb/testsuite/gdb.ada/call_pn/foo.adb:17
> 
...

With 1, we get:
...
> 1
$1 = <optimized out>
...
and with 2:
...
> 2
$1 = 0
...

The fact that we have two matches here was filed as PR gcc/94450.

We only want to find the one with the value, which is choice 2.

However, due to being asked for a choice we can spot that the file for choice 2
is wrong.

Another way to get that info is:
...
$ gdb foo -ex "l last_node_id"
Reading symbols from foo...
file: "src/gdb/testsuite/gdb.ada/call_pn/foo.adb", line number: 17, symbol:
"pck.last_node_id"
file: "src/gdb/testsuite/gdb.ada/call_pn/pck.adb", line number: 17, symbol:
"pck.last_node_id"
...

So, we have the CU for pck.adb:
...
 <0><167a>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <1680>   DW_AT_name        : src/gdb/testsuite/gdb.ada/call_pn/pck.adb
    <1688>   DW_AT_stmt_list   : 0x351
...
containing the DIE for the abstract var:
...
 <1><16d4>: Abbrev Number: 8 (DW_TAG_variable)
    <16d5>   DW_AT_name        : pck__last_node_id
    <16d9>   DW_AT_decl_file   : 2
    <16da>   DW_AT_decl_line   : 17
    <16db>   DW_AT_decl_column : 4
    <16dc>   DW_AT_type        : <0x168c>
...
with the DW_AT_decl_file with value 2 referring to file table at offset 0x351:
...
 The File Name Table (offset 0x390):
  Entry Dir     Time    Size    Name
  1     1       0       0       pck.ads
  2     1       0       0       pck.adb
...
which gets us file pck.adb.

Now the <articifial> CU:
...
 <0><15ef>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <15f5>   DW_AT_name        : <artificial>
    <160d>   DW_AT_stmt_list   : 0x2d3
...
containing the concrete var:
...
 <1><163f>: Abbrev Number: 5 (DW_TAG_variable)
    <1640>   DW_AT_abstract_origin: <0x16d4>
    <1644>   DW_AT_location    : 9 byte block: 3 d4 33 63 0 0 0 0 0    
(DW_OP_addr: 6333d4)
...
apparently inherits the DW_AT_decl_file with value 2, now pointing to the file
table at offset 0x2d3:
...
 The File Name Table (offset 0x311):
  Entry Dir     Time    Size    Name
  1     1       0       0       pck.adb
  2     1       0       0       foo.adb
...
which gets us foo.adb instead off pck.adb.

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

[Bug symtab/25771] Inter-cu DW_AT_abstract_origin results in wrong file

[vries at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca,
                   |                            |tromey at sourceware dot org

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Any opinion on whether gdb is at fault here or not?

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

[Bug symtab/25771] Inter-cu DW_AT_abstract_origin results in wrong file

[simark at simark dot ca]

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

--- Comment #2 from Simon Marchi <simark at simark dot ca> ---
Let me rephrase the problem to make sure I understand.  We have a compile unit
(let's call it Importer) importing (with DW_TAG_imported_unit) another compile
unit (let's call it Importee).  This means that Importer knows about Importee,
but Importee does not know about Importer.

Importee defines a variable (let's call it BaseVar), with a DW_AT_decl_file. 
That number necessarily refers to its own file table.  Importer defines a
variable (let's call it ChildVar) that extends (with DW_AT_abstract_origin)
BaseVar.  ChildVar inherits the DW_AT_decl_file attribute from BaseVar.  The
value of the attribute necessarily refers to Importee's file table.

>From what I understand, GDB currently uses the DW_AT_decl_file value defined by
Importee to look up the file name in Importer's file table.  If that's the
case, I'd say GDB is at fault.

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

[Bug symtab/25771] Inter-cu DW_AT_abstract_origin results in wrong file

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #2)
> Let me rephrase the problem to make sure I understand.

Your rephrasing looks sound to me, thanks.

> If that's
> the case, I'd say GDB is at fault.

OK, we agree then :)

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

[Bug symtab/25771] Inter-cu DW_AT_abstract_origin results in wrong file

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=94450

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

[Bug symtab/25771] Inter-cu DW_AT_abstract_origin results in wrong file

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 12933
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12933&action=edit
Dwarf assembly test-case

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

[Bug symtab/25771] Inter-cu DW_AT_abstract_origin results in wrong file

[vries at gcc dot gnu.org]

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

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

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

[Bug symtab/25771] Inter-cu DW_AT_abstract_origin results in wrong file

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #5)
> Created attachment 12934 [details]
> Tentative patch

I've tested this and found no issues.

However, we may end up reading the line header twice, so I tried this patch to
fix that:
...
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 699d217866..d4f86ee34a 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -11007,7 +11007,6 @@ handle_DW_AT_stmt_list (struct die_info *die, struct
dwarf2_cu
 *cu,
   struct line_header line_header_local;
   hashval_t line_header_local_hash;
   void **slot;
-  int decode_mapping;

   gdb_assert (! cu->per_cu->is_debug_types);

@@ -11023,8 +11022,7 @@ handle_DW_AT_stmt_list (struct die_info *die, struct
dwarf2_cu
 *cu,
      compile_unit, then use the line header hash table if it's already
      created, but don't create one just yet.  */

-  if (per_objfile->line_header_hash == NULL
-      && die->tag == DW_TAG_partial_unit)
+  if (per_objfile->line_header_hash == NULL)
     {
       per_objfile->line_header_hash
        .reset (htab_create_alloc (127, line_header_hash_voidp,
@@ -11045,7 +11043,7 @@ handle_DW_AT_stmt_list (struct die_info *die, struct
dwarf2_cu
 *cu,
       /* For DW_TAG_compile_unit we need info like symtab::linetable which
         is not present in *SLOT (since if there is something in *SLOT then
         it will be for a partial_unit).  */
-      if (die->tag == DW_TAG_partial_unit && slot != NULL)
+      if (slot != NULL)
        {
          gdb_assert (*slot != NULL);
          cu->line_header = (struct line_header *) *slot;
@@ -11087,9 +11085,8 @@ handle_DW_AT_stmt_list (struct die_info *die, struct
dwarf2_cu
 *cu,
         then this is what we want as well.  */
       gdb_assert (die->tag != DW_TAG_partial_unit);
     }
-  decode_mapping = (die->tag != DW_TAG_partial_unit);
   dwarf_decode_lines (cu->line_header, comp_dir, cu, NULL, lowpc,
-                     decode_mapping);
+                     true);

 }

...
and I ran into problems during testing for only one test-case:
...
(gdb) PASS: gdb.dwarf2/fission-multi-cu.exp: frame in main
break func^M
Breakpoint 2 at 0x4004b4^M
(gdb) FAIL: gdb.dwarf2/fission-multi-cu.exp: break func
continue^M
Continuing.^M
^M
Breakpoint 2, 0x00000000004004b4 in func (arg=0)^M
(gdb) FAIL: gdb.dwarf2/fission-multi-cu.exp: continue to func
frame^M
#0  0x00000000004004b4 in func (arg=0)^M
(gdb) FAIL: gdb.dwarf2/fission-multi-cu.exp: frame in func
...
where the FAILs are related to missing printing of source file/line.

Something specific to that test-case is there's a debug_line entry:
...
Raw dump of debug contents of section .debug_line:

  Offset:                      0x0

  ...

 The File Name Table (offset 0x1c):
  Entry Dir     Time    Size    Name
  1     0       0       0       fission-multi-cu1.c
  2     0       0       0       fission-multi-cu2.c
...
that is shared between two compilation units:
...
  Compilation Unit @ offset 0x0:
  ...
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_stmt_list   : 0x0
  Compilation Unit @ offset 0x30:
  ...
 <0><3b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <3c>   DW_AT_stmt_list   : 0x0
...

The .S file is supposed to mimic how clang -g -gsplit-dwarf -flto generates
code, but when I try that using the original source files:
...
$ clang gdb/testsuite/gdb.dwarf2/fission-multi-cu{1,2}.c -g -gsplit-dwarf -flto
...
we have instead non-shared .debug_line entries:
...
  Compilation Unit @ offset 0xc7:
  ...
 <0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <d3>   DW_AT_stmt_list   : 0xe9
  ...
  Compilation Unit @ offset 0xf7:
  ...
 <0><102>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <103>   DW_AT_stmt_list   : 0x155
...

So, perhaps the .S file is just unusual code that does not resemble real use
cases.

I should note that it is possible to get the shared .debug_line entries by
following the commands listed in .S:
...
   clang fission-multi-cu*.c -g -fno-split-dwarf-inlining -emit-llvm -S -c      
   llvm-link fission-multi-cu*.ll -S -o fission-multi-cu.ll                     
   clang fission-multi-cu.ll -gsplit-dwarf -S                                   
...
but I suppose that is hardly typical usage.

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

[Bug symtab/25771] Inter-cu DW_AT_abstract_origin results in wrong file

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #6)

> Something specific to that test-case is there's a debug_line entry:
> ...
> Raw dump of debug contents of section .debug_line:
> 
>   Offset:                      0x0
> 
>   ...
> 
>  The File Name Table (offset 0x1c):
>   Entry Dir     Time    Size    Name
>   1     0       0       0       fission-multi-cu1.c
>   2     0       0       0       fission-multi-cu2.c
> ...
> that is shared between two compilation units:
> ...
>   Compilation Unit @ offset 0x0:
>   ...
>  <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
>     <c>   DW_AT_stmt_list   : 0x0
>   Compilation Unit @ offset 0x30:
>   ...
>  <0><3b>: Abbrev Number: 1 (DW_TAG_compile_unit)
>     <3c>   DW_AT_stmt_list   : 0x0
> ...

FWIW, dwz does generate partial units that share a .debug_line entry with a CU.

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