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

Wed Jan 11 16:15:30 PST 2023

clayborg added a comment.

In D68655#4045461 <https://reviews.llvm.org/D68655#4045461>, @jasonmolenda wrote:

> In D68655#4045423 <https://reviews.llvm.org/D68655#4045423>, @clayborg wrote:
>
>> There have also been some bugs in .debug_aranges and some folks want to get rid of .debug_aranges all together and rely only upon the DW_TAG_compile_unit's DW_AT_ranges. Tons of details in this patch:
>>
>> https://reviews.llvm.org/D136395
>>
>> So long story short, some people believe we should not produce or use .debug_aranges anymore, and want LLDB changed to ignore it.
>
> I'm honestly curious how the DW_TAG_compile_unit's DW_AT_ranges (or DW_AT_high/low_pc) would be authoritative, but the ranges for the CU in debug_aranges would be incorrect.  If the linker is allowed to reorder functions (does this not happen on linux?), then the compiler can't know the address ranges of the CU, only the linker (or post-linker) can know what address ranges are owned by this compile unit.  So the linker had to create the DW_TAG_compile_unit's DW_AT_ranges list after linking is complete, and the linker is also the part of the toolchain that creates debug_aranges.  If it is creating an incorrect debug_aranges entry, how can it possibly do the correct thing when rewriting the DW_TAG_compile_unit's DW_AT_ranges?

They are all the same from the linker perspective: both .debug_aranges (for accelerator table) and .debug_ranges (for DW_AT_ranges) have relocations on them. As linkers move stuff around they apply the relocations and they all stay up to date. Anything without a relocation has its start address zeroed out.

> On Darwin, we usually get a DW_AT_high/low_pc on the compile_unit in the .o files, where all of the functions are contiguous.  When dsymutil links the debug information into the dSYM, it includes the address ranges of every DW_TAG_subprogram that was included in the final executable in the debug_aranges.  It doesn't modify DW_AT_high/low_pc in the compile_unit, it merely updates the addresses to their linked addresses.  But lldb doesn't use those for anything - either it trusts the debug_aranges entries, or lldb scans all of the subprograms itself to construct the aranges (same thing dsymutil did).

dsymutil generates correct .debug_aranges by looking at the final DWARF. Note that there are no .debug_aranges sections in .o files since we don't use them, they only get produced if we have a dSYM for darwin.

> tl;dr I don't see what using DW_AT_ranges in the compile_unit accomplishes versus debug_aranges.

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. Each compiler (GCC and clang) do their own thing and often do things differently. So the other way to add functionality like this would be to check the target triple and check for Apple as the vendor maybe. But we still need know if we have a dSYM file or not, because if not, we can't use .debug_aranges as .o files don't have them, but they also don't claim to be of type ObjectFile::eTypeDebugInfo.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68655