[Lldb-commits] [PATCH] D68655: Trust the arange accelerator tables in dSYMs

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

I know this is all moot because the dSYM-specific patch landed, but I am curious about this part,

In D68655#4045561 <https://reviews.llvm.org/D68655#4045561>, @clayborg wrote:

> 



> Different things are included in DW_AT_ranges, like address ranges for global and static variables. .debug_aranges only has functions, no globals or statics, so if you are trying to find a global variable by address, you can't rely on .debug_aranges. Nothing in the DWARF spec states things clearly enough for different compilers to know what to include in .debug_aranges  and the compiler uint DW_AT_ranges.

The standard says,

"Each descriptor is a triple consisting of a segment selector, the beginning address within that segment of a range of text or data covered by some entry owned by the corresponding compilation unit, followed by the non-zero length of that range"

It is pretty clear on the point that any part of the address space that can be attributed to a compile_unit can be included in the debug_aranges range list - if only code is included, that's a choice of the aranges writer.  lldb itself, if debug_aranges is missing or doesn't include a CU, steps through the line table concatenating addresses for all the line entries in the CU (v. DWARFCompileUnit::BuildAddressRangeTable ) - it doesn't include data.  (it will also use DW_AT_ranges from the compile_unit but I worry more about this being copied verbatim from the .o file into the linked DWARF than I worry about debug_aranges, personally)

In a DW_TAG_compile_unit, the DW_AT_ranges that the compiler puts in the .o file isn't relevant to the final linked debug information, unless it included the discrete range of every item which might be linked into the final binary, and the DWARF linker only copies the range entries that were in the final binary in the linked dwarf DW_AT_ranges range list.   Or if the dwarf linker knows how to scan the DWARF compile_unit like lldb does, concatenating line table entries or DW_TAG_subprogram's.

If any dwarf linker is doing all of this work to construct an accurate & comprehensive compile_unit DW_AT_ranges, why couldn't it be trusted to also have an identical/accurate dwarf_aranges for this cu?  I don't see the difference.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68655/new/

https://reviews.llvm.org/D68655