4e7682b1c4
The class is only used from one place, which is trivial to implement using the llvm class. The main difference is that in the new implementation, the ranges are parsed each time anew (instead of being parsed at startup and cached). I believe this is fine because: - this is already how things work with DWARF v5 debug_rnglists - parsing debug_ranges is fairly fast (definitely faster than rnglists) - generally, this result will be cached at a higher level anyway. Browsing the code I did find one instance where that is not the case -- SymbolFileDWARF::ResolveFunctionAndBlock -- which is called each time we resolve an address (to the block level). However, this function is already pretty suboptimal: it first traverses the DIE tree (which involves parsing all the DIE attributes) to find the correct block, then it parses them again to construct the `lldb_private::Block` representation, and *then* it uses the ID of the block DIE it found in the first step to look up the `Block` object. If this turns out to be a bottleneck, I think there are better ways to optimize it than caching the debug_ranges parse. The motiviation for this is that DWARFDebugRanges sorts the block ranges, even though the order of the ranges is load-bearing (in the absence of DW_AT_low_pc, the "base address" of a scope is determined by the first range entry). Delaying the parsing (and sorting) step makes it easier to access the first entry.
21 KiB
21 KiB