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

?Hi !


I have a question about code used for collecting ranges. I was trying to fix
PR35199.

Its issue that it calls unreachable when calls DWARFObject::getFileName().

We do not implement this method in LLD and it fails.

Issue appears when we start to provide .debug_str

section to DWARF parser. And it is relative to following code (lines 335-339):


https://github.com/llvm-mirror/llvm/blob/master/lib/DebugInfo/DWARF/DWARFUnit.cpp#L335


Object I used for debugging parser is following:

t.ii:
int a;

clang++ -gsplit-dwarf -c t.ii -o t.o


When parser tries to read this object it attemps to extract address ranges from
dwo.

When we don't give it .debug_str it fails to extract dwo name, exits early
and "works" fine, but with

.debug_str provided it tries to take ranges from there, tries to get DWO name to
open it and fails.


Though I did not find why it tries to scan .dwo. I tried to comment these lines
(335-339) and no tests

were failing for me, at least I tried running tests from \llvm\test\DebugInfo
and

running DebugInfoDWARFTests. It seems to me these lines are either untested or
useless (?).


So my question is probably next: what is the case when we need to scan .dwo for
extracting ranges,

should not address data be accessible from main object always ?

I wonder if these lines really do useful job ??

Best regards,
George | Developer | Access Softek, Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171115/511c887a/attachment.html>

On Wed, Nov 15, 2017 at 7:53 AM George Rimar <grimar at accesssoftek.com>
wrote:
> ​Hi !
>
>
> I have a question about code used for collecting ranges. I was trying to
> fix PR35199.
>
> Its issue that it calls unreachable when calls DWARFObject::getFileName().
>
> We do not implement this method in LLD and it fails.
>
> Issue appears when we start to provide .debug_str
>
> section to DWARF parser. And it is relative to following code (lines
> 335-339):
>
>
>
>
https://github.com/llvm-mirror/llvm/blob/master/lib/DebugInfo/DWARF/DWARFUnit.cpp#L335
>
>
> Object I used for debugging parser is following:
>
> t.ii:
> int a;
>
> clang++ -gsplit-dwarf -c t.ii -o t.o
>
> When parser tries to read this object it attemps to extract address ranges
from dwo.
>
> When we don't give it .debug_str it fails to extract dwo name, exits
early and "works" fine, but with
>
> .debug_str provided it tries to take ranges from there, tries to get DWO
name to open it and fails.
>
>
> Though I did not find why it tries to scan .dwo. I tried to comment these
lines (335-339) and no tests
>
> were failing for me, at least I tried running tests from
\llvm\test\DebugInfo and
>
> running DebugInfoDWARFTests. It seems to me these lines are either untested
or useless (?).
>
>
> So my question is probably next: what is the case when we need to scan .dwo
for extracting ranges,
>
> should not address data be accessible from main object always ?
>
> I wonder if these lines really do useful job ?​
>
> 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?

Though, admittedly - the presence of debug_str shouldn't be the deciding
factor that leads to an error. If it's an error not to find the .dwo file,
it seems it should be an error not to find the debug_str that's needed to
get there... but I haven't looked at the code to check - maybe this does
make sense/perhaps there are aspects I haven't considered.

- Dave
> Best regards,
> George | Developer | Access Softek, Inc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171116/ecbfa3e3/attachment.html>

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>