[llvm-dev] Collecting address ranges in DWARFUnit::collectAddressRanges.
Rafael Avila de Espindola via llvm-dev
llvm-dev at lists.llvm.org
Thu Nov 16 15:47:00 PST 2017
David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes:
> On Thu, Nov 16, 2017 at 11:44 AM Robinson, Paul <paul.robinson at sony.com>
>> There's no requirement that DW_AT_ranges (or high/low_pc) appear on the
>> skeleton CU rather than the DWO CU. So it's quite possible that to get the
>> address ranges covered by the CU one would need to look in the DWO, I think?
>> Is that not correct/have I misunderstood something there?
>> The DWO isn't supposed to contain addresses (because it isn't supposed to
>> contain relocations). In DWARF 5 the DWO can have FORM_addrx references to
>> the .debug_addr section in the main .o file, which allows the DWO to
>> contain DIEs/attributes that should have address values, because the actual
>> address values are still in the .o file; but before that anything that's an
>> address really can't go into the DWO.
> DWOs didn't exist (in a standard form) before DWARF 5, right? Insofar as
> they did exist (in a non-standard form) they have always supported
> FORM_addr_index to reference addresses in .debug_addr in the main .o.
> But the low_pc/high_pc/ranges attributes would appear in the .dwo, using a
> FORM_addr_index/FORM_addrx - so if you want to collect the address range of
> a CU you might need to load the .dwo to do so. That's the crux of what I
> was getting at: To get the address range a CU covers, you may need to read
> the .dwo.
Is it possible to add a test for that? I can confirm that the attached
patch causes not failures on llvm, clang or lld tests.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 716 bytes
Desc: not available
More information about the llvm-dev