[llvm-dev] Collecting address ranges in DWARFUnit::collectAddressRanges.

David Blaikie via llvm-dev
2017-11-16T18:03:34Z

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>