[all-commits] [llvm/llvm-project] f7a49d: [WIP][DebugInfo] Lazily parse debug_loclist offsets

[David Blaikie via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: f7a49d2aa691266497c4baa35f29ba0167b39d23
      https://github.com/llvm/llvm-project/commit/f7a49d2aa691266497c4baa35f29ba0167b39d23
  Author: David Blaikie <dblaikie at gmail.com>
  Date:   2020-08-18 (Tue, 18 Aug 2020)

  Changed paths:
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
    M lldb/test/Shell/SymbolFile/DWARF/DW_AT_loclists_base.s
    M llvm/include/llvm/DebugInfo/DWARF/DWARFDebugLoc.h
    M llvm/include/llvm/DebugInfo/DWARF/DWARFListTable.h
    M llvm/include/llvm/DebugInfo/DWARF/DWARFUnit.h
    M llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
    M llvm/lib/DebugInfo/DWARF/DWARFListTable.cpp
    M llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp

  Log Message:
  -----------
  [WIP][DebugInfo] Lazily parse debug_loclist offsets

Parsing DWARFv5 debug_loclist offsets when a CU is parsed is weighing
down memory usage of symbolizers that don't need to parse this data at
all. There's not much benefit to caching these anyway - since they are
O(1) lookup and reading once you know where the offset list starts (and
can do bounds checking with the offset list size too).

In general, I think it might be time to start paying down some of the
technical debt of loc/loclist/range/rnglist parsing to try to unify it a
bit more.

eg:

* Currently DWARFUnit has: RangeSection, RangeSectionBase, LocSection,
  LocSectionBase, LocTable, RngListTable, LoclistTableHeader (be nice if
  these were all wrapped up in two variables - one for loclists, one for
  rnglists)

* rnglists and loclists are handled differently (see:
  LoclistTableHeader, but no RnglistTableHeader)

* maybe all these types could be less stateful - lazily parse what they
  need to, even reparsing rather than caching because it doesn't seem
  too expensive, for instance. (though admittedly so long as it's
  constantcost/overead per compilatiton that's probably adequate)

* Maybe implementing and using a DWARFDataExtractor that can be
  sub-ranged (so we could slice it up to just the single contribution) -
  though maybe that's not so useful because loc/ranges need to refer to
  it by absolute, not contribution-relative mechanisms

Differential Revision: https://reviews.llvm.org/D86110