This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Multi-threaded dwarf parsing
- From: Pedro Alves <palves at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>, Simon Marchi <simon dot marchi at polymtl dot ca>
- Cc: Tom Tromey <tom at tromey dot com>, gdb at sourceware dot org
- Date: Wed, 24 Feb 2016 21:10:46 +0000
- Subject: Re: Multi-threaded dwarf parsing
- Authentication-results: sourceware.org; auth=none
- References: <2c38d5c574de28faa9fc94fe4ed17d45 at simark dot ca> <56CD8EC0 dot 3010304 at redhat dot com> <87lh6a6s8s dot fsf at tromey dot com> <c4dc7b1f07fe11da024684ec2de47a7e at simark dot ca> <20160224202519 dot GA10251 at host1 dot jankratochvil dot net>
On 02/24/2016 08:25 PM, Jan Kratochvil wrote:
> On Wed, 24 Feb 2016 17:43:03 +0100, Simon Marchi wrote:
>> instead of blocking on the psymtabs creation at startup
> [...]
>> then the main code will have to block until the corresponding task is
>> complete (dwarf2_require_psymtabs).
>
> If really your concern are psymtabs then use Tom's .gdb_index:
> gdb/contrib/gdb-add-index.sh
I think the index isn't so helpful if the big thing that takes a
while to read/load is what you're changing in a edit/compile/debug
cycle.
Also, that script actually relies on gdb to read the debug info,
intern it, and spit out the index. So if we gdb reads dwarf faster,
then index generation itself becomes faster too.
>
> With .gdb_index GDB still has startup performance problems during full CU
> expansions, that is struct symtab and struct symbol. That happens with C++
> inferiors which have very interlinked CUs and thus expanding one CU means for
> GDB expanding 100+ CUs due to the inter-type dependencies which cannot be left
> opaque in such cases. And as each C++ CU is usually very large...
Sounds like something that could be sped up by reading CUs in parallel.
Thanks,
Pedro Alves