Re: Multi-threaded dwarf parsing

Pedro Alves <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.