Re: Multi-threaded dwarf parsing

Tom Tromey
2016-02-24T19:50:21Z

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