clayborg added a comment. A little background might help here: The lldb_private::Module lock is used to prevent multiple queries into the DWARF from stomping on each other.
Multi-threaded DWARF parsing was primarily added to speed up indexing and the only place it is used. Is that not true? Indexing is just creating name tables and the accelerator tables we need so that we can partially parse the DWARF later. No type parsing should be happening when indexing. All other accesses to the DWARF must be done via a SymbolFile API that takes the module lock to stop multiple threads from stomping on each other. So my main point is we need to use the module lock to avoid having multiple threads doing important work that will cause crashes. The only multi-threaded access to DWARF currently should be in the indexing only and no important parsing stuff should be going on. If we discover places where multiple threads are making accesses, we just need to ensure they take the module lock and everything should just work. In https://reviews.llvm.org/D48393#1139290, @zturner wrote: > Related question: Is the laziness done to save memory, startup time, or both? Both. Memory is the bigger issue here though. We want to only parse what we need when we need it so if someone was to use LLDB for symbolication, they don't incur the cost of parsing all types in any compile units that get touched (like would happen with GDB). Since we convert all DWARF types into clang AST types, parsing more types than needed can cause a lot of memory to be used. https://reviews.llvm.org/D48393 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
