llvm dev - Nov 2017 - Collecting address ranges in DWARFUnit::collectAddressRanges.

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.

Unless I am also misunderstanding something…
--paulr

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171116/99922a6e/attachment.html>

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.

>
>
> Unless I am also misunderstanding something…
>
> --paulr
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171116/60a4a68d/attachment.html>

Ah right, the GNU forms.  Yes, I did forget about those.  So, reading the DWO
units can be necessary.
--paulr

From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Thursday, November 16, 2017 12:20 PM
To: Robinson, Paul
Cc: George Rimar; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Collecting address ranges in
DWARFUnit::collectAddressRanges.


On Thu, Nov 16, 2017 at 11:44 AM Robinson, Paul <paul.robinson at
sony.com<mailto: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.


Unless I am also misunderstanding something…
--paulr

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171116/c3bb9bc8/attachment.html>

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>