public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Mark Wielaard <mark@klomp.org>
Cc: gdb@sourceware.org
Subject: Re: DWARF5 and .gdb_index/.debug_names
Date: Mon, 31 Aug 2020 10:28:26 +0200	[thread overview]
Message-ID: <20200831082826.GA2164630@host1.jankratochvil.net> (raw)
In-Reply-To: <e56fb5e13a0e04a40fc1c88205d3c0eaaa71919a.camel@klomp.org>

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

On Sun, 30 Aug 2020 19:18:51 +0200, Mark Wielaard wrote:
> During the BoF Pedro mentioned that the GDB DWARF5 .debug_names support
> is incomplete/wrong. I was wondering whether there was a good
> description of the issue and/or a bug report for it. When using the
> contrib/gdb-add-index.sh it does add a .gdb_index for objects
> containing DWARF5 and the results seem correct, gdb also seems to be
> able to use it. When adding -dwarf-5 it seems to output a .debug_names
> section which can be read by binutils readelf (elfutils doesn't yet
> support .debug_names). I couldn't immediately see in what way it was
> wrong/incomplete.

.debug_names from GDB needs to produce also DW_IDX_die_offset to make it
consumable by debuggers with reasonable performance.

Then I see clang++ -gdwarf-5 -gpubnames produces C++ names mangled while GDB
produces them unmangled. I haven't found anything in DWARF-5 standard
suggesting either. Given mangled->unmangled mapping is possible but
unmangled->mangled is not (such as variants of ctors/dtors) I find the clang
way should be followed.


Jan

[-- Attachment #2: ns3.debug_names --]
[-- Type: text/plain, Size: 1818 bytes --]

ns3:	file format ELF64-x86-64

.debug_names contents:
Name Index @ 0x0 {
  Header {
    Length: 0xC4
    Version: 5
    Padding: 0x0
    CU count: 1
    Local TU count: 0
    Foreign TU count: 0
    Bucket count: 5
    Name count: 5
    Abbreviations table size: 0x19
    Augmentation: 'LLVM0700'
  }
  Compilation Unit offsets [
    CU[0]: 0x00000000
  ]
  Abbreviations [
    Abbreviation 0x34 {
      Tag: DW_TAG_variable
      DW_IDX_die_offset: DW_FORM_ref4
    }
    Abbreviation 0x2 {
      Tag: DW_TAG_class_type
      DW_IDX_die_offset: DW_FORM_ref4
    }
    Abbreviation 0x2e {
      Tag: DW_TAG_subprogram
      DW_IDX_die_offset: DW_FORM_ref4
    }
    Abbreviation 0x24 {
      Tag: DW_TAG_base_type
      DW_IDX_die_offset: DW_FORM_ref4
    }
  ]
  Bucket 0 [
    EMPTY
  ]
  Bucket 1 [
    Name 1 {
      Hash: 0x7C9A7F6A
      String: 0x00000052 "main"
      Entry @ 0x99 {
        Abbrev: 0x2E
        Tag: DW_TAG_subprogram
        DW_IDX_die_offset: 0x00000041
      }
    }
  ]
  Bucket 2 [
    Name 2 {
      Hash: 0x2B608
      String: 0x00000030 "C"
      Entry @ 0xa2 {
        Abbrev: 0x2
        Tag: DW_TAG_class_type
        DW_IDX_die_offset: 0x0000002c
      }
    }
  ]
  Bucket 3 [
    Name 3 {
      Hash: 0x2B60E
      String: 0x00000043 "i"
      Entry @ 0xab {
        Abbrev: 0x34
        Tag: DW_TAG_variable
        DW_IDX_die_offset: 0x00000023
      }
    }
    Name 4 {
      Hash: 0xB888030
      String: 0x00000045 "int"
      Entry @ 0xb4 {
        Abbrev: 0x24
        Tag: DW_TAG_base_type
        DW_IDX_die_offset: 0x0000003d
      }
    }
    Name 5 {
      Hash: 0xDBA78B3F
      String: 0x00000049 "_ZN1C1iE"
      Entry @ 0xbd {
        Abbrev: 0x34
        Tag: DW_TAG_variable
        DW_IDX_die_offset: 0x00000023
      }
    }
  ]
  Bucket 4 [
    EMPTY
  ]
}

[-- Attachment #3: ns3g.debug_names --]
[-- Type: application/octet-stream, Size: 2120 bytes --]

[-- Attachment #4: ns3.C --]
[-- Type: text/plain, Size: 73 bytes --]

class C {
public:
static inline int i=42;
};
int main() { return C::i; }

  parent reply	other threads:[~2020-08-31  8:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-30 17:18 Mark Wielaard
2020-08-31  7:21 ` Tom de Vries
2020-08-31  8:28 ` Jan Kratochvil [this message]
2020-09-01  3:07   ` David Blaikie
2020-09-01 18:38 ` Tom Tromey
2020-09-01 18:53   ` David Blaikie
2020-09-01 19:16 ` Pedro Alves
2020-09-01 22:00   ` Eric Christopher
2020-09-14 15:23 ` Gaius Mulley

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=20200831082826.GA2164630@host1.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=mark@klomp.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).