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

Fri Jan 13 14:26:55 PST 2023

clayborg added a comment.

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

> In D68655#4047126 <https://reviews.llvm.org/D68655#4047126>, @labath wrote:
>
>> In D68655#4045895 <https://reviews.llvm.org/D68655#4045895>, @jasonmolenda wrote:
>>
>>> Both have to be written by the dwarf linker to be correct, but only the former is written ONLY by the dwarf linker.
>>
>> I don't think that's right:
>>
>>   $ clang -c -x c - -o - -gdwarf-aranges -g <<<"void f(){}" | llvm-readelf - --sections | grep aranges
>>     [ 6] .debug_aranges    PROGBITS        0000000000000000 0000a0 000030 00      0   0  1
>>     [ 7] .rela.debug_aranges RELA          0000000000000000 000380 000030 18   I 20   6  8
>
> Ah thanks Pavel, clang on Darwin doesn't emit this in .o files.  So in this case, the .o file has a DW_TAG_compile_unit with a DW_AT_ranges and a .debug_aranges, both generated pre-link-time by the compiler.  And Greg is saying that the DW_AT_ranges list in the final executable will be better than the .debug_aranges?  I don't know how strongly he asserts this - today if a .debug_aranges has an entry, we don't look at DW_TAG_compile_unit's DW_AT_ranges, or create the ranges ourself via the line table; the debug_aranges is trusted above the other methods if it includes CU.

It isn't better or worse and it varies per compiler. I believe, but I don't remember for sure, that DW_AT_ranges only currently has code address ranges (no data, so no globals or statics). So if a compiler in fact does include data in the .debug_aranges, it would be better to use .debug_aranges.

I tried to add a verifier into llvm-dwarfdump to catch when either .debug_aranges or DW_AT_ranges on the CU didn't contain some address ranges that were in the CU with:

https://reviews.llvm.org/D136395

The problem is the debugger has issues if either of these tables are incorrect, so you would think a verifier would be a good thing since if the address isn't in either .debug_aranges or DW_AT_ranges, we won't ever find a DIE for a function or global variable. I had seen bugs where we have .debug_aranges that didn't include all ranges for all DW_TAG_subprogram DIEs, and also cases where DW_AT_ranges didn't have some ranges. This usually happens when someone tries to LTO or optimize a binary and the DWARF didn't have a dedicate entry for a function, so it would drop address ranges from the .debug_aranges or DW_AT_ranges. Since everything non Darwin uses "concatenate + relocate" in the linker, image if you have a .debug_aranges entry that had [0x1000-0x2000), and you had DWARF with two functions that fall into those ranges: [0x1000-0x1500) for "func1" and [0x1500-0x2000) for "func2", and those functions get optimized into different places in the binary (not right next to each other), then there is no valid relocation to can apply to the range [0x1000-0x2000) that will make the table continue to work after linking. You will end up relocating the 0x1000 address correctly for "func1", and if you apply the relocation for the end address of 0x2000, you can end up setting it to the end address of 0x2000, which could be less that the new address for the start of "func1". So lots of stuff goes wrong in the linking phase, especially when LTO is involved.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68655