This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Multi-threaded dwarf parsing
- From: Simon Marchi <simon dot marchi at polymtl dot ca>
- To: gdb at sourceware dot org
- Cc: tromey at redhat dot com
- Date: Tue, 23 Feb 2016 21:45:40 -0500
- Subject: Multi-threaded dwarf parsing
- Authentication-results: sourceware.org; auth=none
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?
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?
Simon