Re: Multi-threaded dwarf parsing

[Pedro Alves <palves@redhat.com>]

[Updated Tom's address]

On 02/24/2016 02:45 AM, Simon Marchi wrote:
> Hi all,
> 
> When debugging large programs, simply loading the binary in gdb can take 
> a significant amount of time.  I was wondering if the dwarf parsing 
> (building partial and/or full symtabs, I suppose) could be a good 
> candidate for parallelization.  I did some quick checks to determine 
> that, at least when reading from my SSD drive, the operation is not 
> IO-bound.  Also, according to my limited understanding of the Dwarf 
> format, it seems like the compilation units DIEs are entities that could 
> be processed independently.  These two facts, if we assume they are 
> true, suggest that there is a good potential for performance gain here.
> 
> I couldn't find anything on the mailing list about that, please point 
> out any discussion I might have missed.
> 
> I found (and it was a very good surprise) this branch by Tom Tromey:
> 
> https://github.com/tromey/gdb/tree/threaded-dwarf-reader
> 
> According to his description (from https://github.com/tromey/gdb/wiki): 
> "I think it doesn't help any real-world case".  I'd like to ask you 
> directly, Tom: now that you debug Firefox (i.e. a quite large program) 
> daily with gdb, are you still of the same opinion?  Of course, I'm also 
> interested in what others have to say about that.  Is it something that 
> would have value, you think?

Making GDB load debug info faster, and making it take advantage of
the multiple cores in most host machines nowadays definitely adds value.

( I'd also like to get threads into GDB for other reasons, so this would
be a good trojan.  Oh, whoops, did I say that out loud? :-) )

> 
> Also, since not so long ago, LLDB does it.  Apparently, it "can 
> drastically incrase the speed of loading debug info" (sic).  If it's 
> good for LLDB, I don't see why it wouldn't be good for GDB.
> Ref: http://blog.llvm.org/2015/10/llvm-weekly-95-oct-26th-2015.html
> 
> So, in a word, are there any gotchas or good reasons not do take this 
> path?

The obvious gotchas are of course all the globals, and coming up with
fine enough locking granularity that threads actually do run in parallel.

Thanks,
Pedro Alves