public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "dblaikie at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/99178] Emit .debug_names
Date: Wed, 10 Jan 2024 01:20:44 +0000	[thread overview]
Message-ID: <bug-99178-4-aL3XziXu6k@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-99178-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178

David Blaikie <dblaikie at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dblaikie at gmail dot com

--- Comment #4 from David Blaikie <dblaikie at gmail dot com> ---
(In reply to Mark Wielaard from comment #3)
> So if the compiler would emit the .debug_name index would that make any
> link/post-processing steps easier or more efficient?

Right - that's the intent. You can omit the hash table part of .debug_names -
in which case it's just like a newer pubnames/pubtypes - maybe with the
opportunity to have more guaranteed contents (the lack of those guarantees I
think is why debug_gnu_pubnames/types came to be, yeah?).

At least on the lld side, we're working on adding the requisite merging - like
`-Wl,--gdb-index`, except instead of merging debug_gnu_pubnames/pubtypes ->
gdb_index, it merges debug_names -> debug_names.

This is relevant/important/necessary for Split DWARF in particular, where the
linker wouldn't have access to the DWARF to index it anyway (& you don't always
want to run the dwp tool, which would have access to all the DWARF to index it
- but it'd be nice to avoid that in iterative developer scenarios, and save it
only for archival situations) - and even if you do have all the DWARF, it's
certainly faster to merge some tables than to reparse all the DWARF from
scratch.

It'd be great to get GCC/GDB folks take on the name tables - get some practical
experience with their contents, file any bugs about missing elements, etc. It's
possible they're leaning too heavily towards lldb's style of name lookup since
they derived from an existing apple implementation there & it'd be good to
generalize them where needed.

  parent reply	other threads:[~2024-01-10  1:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-20  0:20 [Bug debug/99178] New: " tromey at gcc dot gnu.org
2021-02-22  8:44 ` [Bug debug/99178] " rguenth at gcc dot gnu.org
2021-02-22  9:00 ` jakub at gcc dot gnu.org
2021-02-22 21:40 ` mark at gcc dot gnu.org
2024-01-10  1:20 ` dblaikie at gmail dot com [this message]
2024-01-10  2:47 ` tromey at gcc dot gnu.org
2024-01-10 18:51 ` dblaikie at gmail dot com
2024-01-10 20:31 ` tromey at gcc dot gnu.org

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-99178-4-aL3XziXu6k@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.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).