From: Tom Tromey <tom@tromey.com>
To: Simon Marchi <simark@simark.ca>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH v2 00/32] Rewrite the DWARF "partial" reader
Date: Wed, 10 Nov 2021 12:56:00 -0700 [thread overview]
Message-ID: <87bl2rhjjj.fsf@tromey.com> (raw)
In-Reply-To: <b57530e4-2626-72c1-35e0-27de89a78ad0@simark.ca> (Simon Marchi's message of "Mon, 8 Nov 2021 12:41:24 -0500")
Simon> What I think I understand is that with the new indexer, we gather
Simon> essentially the same information that we gather today with partial
Simon> symbols (just the information needed for doing lookups and expanding
Simon> symtabs), but store it in a data structure that is better designed,
Simon> letting us do more in parallel. Does that sounds right? If not, can
Simon> you explain what's the main difference?
Yeah, the biggest gains are due to parallelism. The single largest
user-visible change comes from pushing the necessary post-processing
into a background thread.
However there are various smaller gains in the series as well:
* Abbrevs are analyzed statically, so we can skip many more DIEs without
examining their contents.
* The partial DIE cache is eliminated.
* Name canonicalization is done just on the name in the DIE,
rather than constructing a full name and then canonicalizing the
entire thing.
* The abbrev cache may also speed up DWARF scanning in some scenarios.
Simon> What sounds nice with partial symtabs is that they are re-used by
Simon> different debug formats, so each format doesn't need to implement its
Simon> own data structures to manage symtab lookups and expansion.
True, but this is also a drawback, because psymtabs weren't really
designed for DWARF. I tried many times to speed up the existing reader,
and couldn't make it work...
Also, another way to look at this is that the new approach shares more
code with the existing DWARF index readers. It also provides the
possibility of making the .debug_names writer work correctly (currently
it is far from what the standard requires).
Simon> How much is
Simon> that new DWARF indexer really DWARF-specific (the part that parses the
Simon> DWARF obviously is, but the part that holds names and stuff)? Could it
Simon> one day be used by other debug formats?
Not readily, because AFAIK the other debug formats aren't hierarchical
in nature. Except for Ada (which as always works in its own way), the
new reader uses the hierarchical nature of DWARF to simplify the
resulting data structure. (For Ada, this same thing is done, but in a
post-processing step.)
Tom
prev parent reply other threads:[~2021-11-10 19:58 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-04 18:08 Tom Tromey
2021-11-04 18:08 ` [PATCH v2 01/32] Introduce make_unique_xstrndup Tom Tromey
2021-11-05 19:20 ` Simon Marchi
2021-11-05 20:08 ` Tom Tromey
2021-11-04 18:08 ` [PATCH v2 02/32] Split create_addrmap_from_aranges Tom Tromey
2021-11-04 18:08 ` [PATCH v2 03/32] Add dwarf2_per_cu_data::addresses_seen Tom Tromey
2021-11-04 18:08 ` [PATCH v2 04/32] Refactor dwarf2_get_pc_bounds Tom Tromey
2021-11-05 19:51 ` Simon Marchi
2021-11-24 15:53 ` Tom Tromey
2021-11-04 18:08 ` [PATCH v2 05/32] Allow ada_decode not to decode operators Tom Tromey
2021-11-04 18:08 ` [PATCH v2 06/32] Let skip_one_die not skip children Tom Tromey
2021-11-04 18:08 ` [PATCH v2 07/32] Add name splitting Tom Tromey
2021-11-04 18:08 ` [PATCH v2 08/32] Add new overload of dwarf5_djb_hash Tom Tromey
2021-11-05 20:01 ` Simon Marchi
2021-11-07 17:02 ` Tom Tromey
2021-11-04 18:08 ` [PATCH v2 09/32] Refactor build_type_psymtabs_reader Tom Tromey
2021-11-04 18:08 ` [PATCH v2 10/32] Add batching parameter to parallel_for_each Tom Tromey
2021-11-04 18:08 ` [PATCH v2 11/32] Return vector of results from parallel_for_each Tom Tromey
2021-11-17 20:37 ` Lancelot SIX
2021-11-18 14:41 ` Tom Tromey
2021-11-04 18:08 ` [PATCH v2 12/32] Specialize std::hash for gdb_exception Tom Tromey
2021-11-04 18:08 ` [PATCH v2 13/32] Introduce DWARF abbrev cache Tom Tromey
2021-11-04 18:08 ` [PATCH v2 14/32] Statically examine abbrev properties Tom Tromey
2021-11-04 18:08 ` [PATCH v2 15/32] Update skip_one_die for new " Tom Tromey
2021-11-04 18:08 ` [PATCH v2 16/32] Introduce the new DWARF index class Tom Tromey
2021-11-04 18:08 ` [PATCH v2 17/32] The new DWARF indexer Tom Tromey
2021-11-04 18:08 ` [PATCH v2 18/32] Implement quick_symbol_functions for cooked DWARF index Tom Tromey
2021-11-04 18:08 ` [PATCH v2 19/32] Wire in the new DWARF indexer Tom Tromey
2021-11-04 18:08 ` [PATCH v2 20/32] Introduce thread-safe handling for complaints Tom Tromey
2021-11-04 18:08 ` [PATCH v2 21/32] Pre-read DWARF section data Tom Tromey
2021-11-04 18:08 ` [PATCH v2 22/32] Parallelize DWARF indexing Tom Tromey
2021-11-04 18:08 ` [PATCH v2 23/32] "Finalize" the DWARF index in the background Tom Tromey
2021-11-04 18:08 ` [PATCH v2 24/32] Rename write_psymtabs_to_index Tom Tromey
2021-11-04 18:09 ` [PATCH v2 25/32] Change the key type in psym_index_map Tom Tromey
2021-11-04 18:09 ` [PATCH v2 26/32] Change parameters to write_address_map Tom Tromey
2021-11-04 18:09 ` [PATCH v2 27/32] Genericize addrmap handling in the DWARF index writer Tom Tromey
2021-11-04 18:09 ` [PATCH v2 28/32] Adapt .gdb_index writer to new DWARF scanner Tom Tromey
2021-11-04 18:09 ` [PATCH v2 29/32] Adapt .debug_names " Tom Tromey
2021-11-04 18:09 ` [PATCH v2 30/32] Enable the new DWARF indexer Tom Tromey
2021-11-04 18:09 ` [PATCH v2 31/32] Delete DWARF psymtab code Tom Tromey
2021-11-04 18:09 ` [PATCH v2 32/32] Remove dwarf2_per_cu_data::v Tom Tromey
2021-11-06 12:25 ` [PATCH v2 00/32] Rewrite the DWARF "partial" reader Tom de Vries
2021-11-11 12:23 ` Tom de Vries
2021-11-16 23:56 ` Tom Tromey
2021-11-17 9:22 ` Tom de Vries
2021-11-18 14:43 ` Tom Tromey
2021-11-22 19:59 ` Tom Tromey
2021-11-22 20:52 ` Tom de Vries
2021-11-22 22:11 ` Tom Tromey
2021-11-23 7:56 ` Tom de Vries
2021-11-23 17:00 ` Tom Tromey
2021-11-08 17:41 ` Simon Marchi
2021-11-10 19:56 ` Tom Tromey [this message]
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=87bl2rhjjj.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
/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).