llvm dev - Feb 2018 - Collecting address ranges in DWARFUnit::collectAddressRanges.

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>
> wrote:
>
>> 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.

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.diff
Type: text/x-patch
Size: 716 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171116/1e3980ca/attachment.bin>

Totally fair call, sorry it took me a while to come back around to this -
added in r324702

On Thu, Nov 16, 2017 at 3:47 PM Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:
> 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>
> > wrote:
> >
> >> 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.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180209/a9e0f9e3/attachment.html>

>Totally fair call, sorry it took me a while to come back around to this -
added in r324702
Thanks ! Have a question: does it need "requres shell" ?
I tried without and it worked for me under windows (had to change check to
CHECK: .{{\\|/}}test.cpp:2:51 though).
And I see nothing special probably that might require shell I think. We use
cd/rm/cp in LLD testcases
without requiring shell.
(also noticed other tests do that, so it seems consistent, though did not look
deeply)

George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180209/dc415f18/attachment-0001.html>