public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug symtab/26834] New: [gsplit-dwarf] Sharing .debug_line entry between CUs results in too many symtabs
Date: Mon, 02 Nov 2020 19:23:09 +0000	[thread overview]
Message-ID: <bug-26834-4717@http.sourceware.org/bugzilla/> (raw)

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.

                 reply	other threads:[~2020-11-02 19:23 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-26834-4717@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).