This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Multi-threaded dwarf parsing
- From: Tom Tromey <tom at tromey dot com>
- To: Simon Marchi <simon dot marchi at polymtl dot ca>
- Cc: Tom Tromey <tom at tromey dot com>, Pedro Alves <palves at redhat dot com>, gdb at sourceware dot org
- Date: Wed, 24 Feb 2016 12:50:07 -0700
- 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>
Simon> Just to make sure I understand correctly: instead of blocking on
Simon> the psymtabs creation at startup (in elf_symfile_read), you
Simon> offload that to worker threads and carry on. If you happen to
Simon> need the information and it's not ready yet, then the main code
Simon> will have to block until the corresponding task is complete
Simon> (dwarf2_require_psymtabs).
That's correct.
Simon> However, in each worker thread, each objfile is still processed
Simon> sequentially. So if you are waiting for libxul.so's debug info
Simon> to be ready (such as in #1), it won't be ready any faster. Is
Simon> that right?
Yes, each task constructs the psymtabs for an entire objfile.
Simon> My view of the parallelism was that when reading an objfile's
Simon> debug info, the main thread would offload chunks of work (a chunk
Simon> == a CU) to the worker threads, but wait for all of them to be
Simon> done before continuing. So it would still be blocking on the
Simon> psymtab creation, but it would block for a shorter time (divided
Simon> by the number of threads/cores, in an ideal world). It's just
Simon> replacing a serial algorithm by a parallel one, but it would be
Simon> mostly transparent to the rest of gdb.
Yeah. This sounds doable in the abstract; though of course details
matter. The DWARF reader has a lot of per-objfile state that would have
to be split up (ideally) or locked. And there is stuff like buildsym.h,
which is full of globals for no good reason.
Simon> I hadn't thought of reading the info in the background, but I
Simon> like the fact that it can get the user to a prompt faster. And I
Simon> think these two forms of parallelism are not mutually exclusive,
Simon> we could very well read CUs in parallel, in the background.
I agree.
Tom