[all-commits] [llvm/llvm-project] 4e7682: [lldb] rm DWARFDebugRanges (#116379)

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4e7682b1c47d4bd81acb6bcb028b48a4ebff9117
      https://github.com/llvm/llvm-project/commit/4e7682b1c47d4bd81acb6bcb028b48a4ebff9117
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2024-11-18 (Mon, 18 Nov 2024)

  Changed paths:
    M lldb/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.h
    R lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp
    R lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
    M lldb/test/Shell/SymbolFile/DWARF/x86/debug_ranges-missing-section.s

  Log Message:
  -----------
  [lldb] rm DWARFDebugRanges (#116379)

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.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications