public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug symtab/26834] New: [gsplit-dwarf] Sharing .debug_line entry between CUs results in too many symtabs
@ 2020-11-02 19:23 vries at gcc dot gnu.org
  0 siblings, 0 replies; only message in thread
From: vries at gcc dot gnu.org @ 2020-11-02 19:23 UTC (permalink / raw)
  To: gdb-prs

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

            Bug ID: 26834
           Summary: [gsplit-dwarf] Sharing .debug_line entry between CUs
                    results in too many symtabs
           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.dwarf2/fission-multi-cu.exp.  The exec and .dwo files
are generated from a .S that is supposed to represent how clang -flto
-gsplit-dwarf -g generates code.

Something seems to be off in the way that symtabs are read in:
...
$ gdb -batch \
  -iex "set debug-file-directory ./outputs/gdb.dwarf2/fission-multi-cu" \
  outputs/gdb.dwarf2/fission-multi-cu/fission-multi-cu \
  -ex start \
  -ex "b func" \
-ex "maint info symtabs" 
Temporary breakpoint 1 at 0x4004d9: file fission-multi-cu2.c, line 24.

Temporary breakpoint 1, main () at fission-multi-cu2.c:24
24      fission-multi-cu2.c: No such file or directory.
Breakpoint 2 at 0x4004b7: file fission-multi-cu1.c, line 21.
{ objfile fission-multi-cu ((struct objfile *) 0x21280f0)
  { ((struct compunit_symtab *) 0x2444ec0)
    debugformat DWARF 2
    producer clang version 5.0.0 (trunk 302855) (llvm/trunk 302853)
    dirname /tmp/src/gdb/testsuite
    blockvector ((struct blockvector *) 0x2445490)
    user ((struct compunit_symtab *) (null))
        { symtab fission-multi-cu1.c ((struct symtab *) 0x2444f50)
          fullname /tmp/src/gdb/testsuite/fission-multi-cu1.c
          linetable ((struct linetable *) 0x2445520)
        }
        { symtab fission-multi-cu2.c ((struct symtab *) 0x2444f80)
          fullname (null)
          linetable ((struct linetable *) 0x24454c0)
        }
  }
  { ((struct compunit_symtab *) 0x23ecb20)
    debugformat DWARF 2
    producer clang version 5.0.0 (trunk 302855) (llvm/trunk 302853)
    dirname /tmp/src/gdb/testsuite
    blockvector ((struct blockvector *) 0x2444da0)
    user ((struct compunit_symtab *) (null))
        { symtab fission-multi-cu2.c ((struct symtab *) 0x23ecbe0)
          fullname (null)
          linetable ((struct linetable *) 0x2444e40)
        }
        { symtab fission-multi-cu1.c ((struct symtab *) 0x23ecbb0)
          fullname (null)
          linetable ((struct linetable *) 0x2444dd0)
        }
  }
}
...

Both fission-multi-cu1.c and fission-multi-cu2.c appear twice, not once.

In contrast, if I do:
...
$ clang -g -gsplit-dwarf -flto
./src/gdb/testsuite/gdb.dwarf2/fission-multi-cu*.c
...
we get:
...
$ gdb -batch \
  -iex "set debug-file-directory ." \
  a.out \
  -ex start \
  -ex "b func" \
  -ex "maint info symtabs"                                                  
Temporary breakpoint 1 at 0x4004b4: file
./src/gdb/testsuite/gdb.dwarf2/fission-multi-cu2.c, line 23.

Temporary breakpoint 1, main () at
./src/gdb/testsuite/gdb.dwarf2/fission-multi-cu2.c:23
23        func (-1);
Breakpoint 2 at 0x4004a7: file
./src/gdb/testsuite/gdb.dwarf2/fission-multi-cu1.c, line 21.
{ objfile /home/vries/gdb_versions/devel/a.out ((struct objfile *) 0x3d3d0f0)
  { ((struct compunit_symtab *) 0x4055d70)
    debugformat DWARF 2
    producer clang version 10.0.1 
    dirname /home/vries/gdb_versions/devel
    blockvector ((struct blockvector *) 0x4056310)
    user ((struct compunit_symtab *) (null))
        { symtab ./src/gdb/testsuite/gdb.dwarf2/fission-multi-cu1.c ((struct
symtab *) 0x4055e00)
          fullname
/home/vries/gdb_versions/devel/binutils-gdb.git/gdb/testsuite/gdb.dwarf2/fission-multi-cu1.c
          linetable ((struct linetable *) 0x4056340)
        }
  }
  { ((struct compunit_symtab *) 0x4001ac0)
    debugformat DWARF 2
    producer clang version 10.0.1 
    dirname /home/vries/gdb_versions/devel
    blockvector ((struct blockvector *) 0x4055cc0)
    user ((struct compunit_symtab *) (null))
        { symtab ./src/gdb/testsuite/gdb.dwarf2/fission-multi-cu2.c ((struct
symtab *) 0x4001b50)
          fullname
/home/vries/gdb_versions/devel/binutils-gdb.git/gdb/testsuite/gdb.dwarf2/fission-multi-cu2.c
          linetable ((struct linetable *) 0x4055cf0)
        }
  }
}
...

A difference between the two is that in the former case the same .debug_line
bit is used for both CUs:
...
  Offset:                      0xe9
  ...
 The File Name Table (offset 0x105):
  Entry Dir     Time    Size    Name
  1     0       0       0       fission-multi-cu1.c
  2     0       0       0       fission-multi-cu2.c
...
and in the latter case each CU has it's own .debug_line bit:
...
  Offset:                      0xe9
  ...
The Directory Table (offset 0x105):
  1     ./src/gdb/testsuite/gdb.dwarf2

 The File Name Table (offset 0x125):
  Entry Dir     Time    Size    Name
  1     1       0       0       fission-multi-cu1.c

  Offset:                      0x15b
  ...
 The Directory Table (offset 0x177):
  1     ./src/gdb/testsuite/gdb.dwarf2

 The File Name Table (offset 0x197):
  Entry Dir     Time    Size    Name
  1     1       0       0       fission-multi-cu2.c
...

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2020-11-02 19:23 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-02 19:23 [Bug symtab/26834] New: [gsplit-dwarf] Sharing .debug_line entry between CUs results in too many symtabs vries at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).