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/31771] New: [gdb/symtab] gdb fails to handle comdat .debug_info.dwo sections
Date: Tue, 21 May 2024 10:12:19 +0000	[thread overview]
Message-ID: <bug-31771-4717@http.sourceware.org/bugzilla/> (raw)

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

            Bug ID: 31771
           Summary: [gdb/symtab] gdb fails to handle comdat
                    .debug_info.dwo sections
           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 this exec with v5 split dwarf and type units:
...
$ gcc ./src/gdb/testsuite/gdb.base/style.c -gsplit-dwarf -gdwarf-5
-fdebug-types-section
...

When trying it out with gdb we get:
...
$ gdb -q -batch a.out -ex start -ex "p main"
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, 4
or 5) [in module /data/vries/gdb/a-style.dwo]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, 4
or 5) [in module /data/vries/gdb/a-style.dwo]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, 4
or 5) [in module /data/vries/gdb/a-style.dwo]
...

The problem is that we have 4 .debug_info sections:
...
$ readelf -WS a-style.dwo 
There are 12 section headers, starting at offset 0x500:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg
Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00     
0   0  0
  [ 1] .debug_info.dwo   PROGBITS        0000000000000000 000040 000039 00     
0   0  1
  [ 2] .debug_info.dwo   PROGBITS        0000000000000000 000079 00005d 00     
0   0  1
  [ 3] .debug_info.dwo   PROGBITS        0000000000000000 0000d6 000039 00     
0   0  1
  [ 4] .debug_info.dwo   PROGBITS        0000000000000000 00010f 000094 00   E 
0   0  1
  [ 5] .debug_abbrev.dwo PROGBITS        0000000000000000 0001a8 0000b7 00  CE 
0   0  8
  [ 6] .debug_line.dwo   PROGBITS        0000000000000000 000260 000075 00  CE 
0   0  8
  [ 7] .debug_str_offsets.dwo PROGBITS        0000000000000000 0002d8 000055 00
 CE  0   0  8
  [ 8] .debug_str.dwo    PROGBITS        0000000000000000 000330 00010e 00  CE 
0   0  8
  [ 9] .symtab           SYMTAB          0000000000000000 000440 000048 18    
10   3  8
  [10] .strtab           STRTAB          0000000000000000 000488 000001 00     
0   0  1
  [11] .shstrtab         STRTAB          0000000000000000 000489 000073 00     
0   0  1
...

Looking at the section from where we're trying to read when we run into the
error:
...
(gdb) p *section
$28 = {s = {section = 0x7fffdc00b6c8, containing_section = 0x7fffdc00b6c8},
buffer = 0x7fffdc004ec0 "5", size = 148, 
  virtual_offset = 0, readin = true, is_virtual = false}
...
the size fits the fourth .debug_info.dwo section, but the buffer seems to be
pointing after the initial_length of the first one.

Note that the four sections are there due to:
...
$ fgrep .section a-style.s
        .section        .rodata
        .section       
.debug_info.dwo,"G",@progbits,wi.c223348ce2059bf5,comdat
        .section       
.debug_info.dwo,"G",@progbits,wi.b5c6873c52ee5e97,comdat
        .section       
.debug_info.dwo,"G",@progbits,wi.dc35a620fa602b61,comdat
        .section        .debug_addr,"",@progbits
        .section        .debug_info.dwo,"e",@progbits
        .section        .debug_info,"",@progbits
        .section        .debug_abbrev,"",@progbits
        .section        .debug_abbrev.dwo,"e",@progbits
        .section        .debug_gnu_pubnames,"",@progbits
        .section        .debug_gnu_pubtypes,"",@progbits
        .section        .debug_aranges,"",@progbits
        .section        .debug_line,"",@progbits
        .section        .debug_line.dwo,"e",@progbits
        .section        .debug_str,"MS",@progbits,1
        .section        .debug_str_offsets.dwo,"e",@progbits
        .section        .debug_str.dwo,"e",@progbits
        .section        .note.GNU-stack,"",@progbits
...

I initially thought this was a problem with the dwarf itself, but the dwarf
standard allows this.

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

                 reply	other threads:[~2024-05-21 10:12 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-31771-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).