<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Aug 1, 2017 at 3:16 AM George Rimar via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">grimar added a comment.<br>
<br>
> A recent improvement to LLVM produces DWARF compliant, but (apparently)<br>
> infrequently used range lists - using base address selection entries to<br>
> reduce the number of relocations required (& reduce file size &<br>
> hopefully link time)<br>
><br>
> This breaks lld's use of LLVM's libDebugInfo which isn't correctly<br>
> tracking the section index in the presence of this kind of debug info.<br>
<br>
Do you have any sample code/testcase/anything that shows/can help to reproduce the issue ?<br>
(looking at implementation I think I know how to generate DWARF section content manually, but I<br>
am not sure what should I do to reproduce issue using cpp+clang for example).<br></blockquote></div><div dir="ltr"><div class="gmail_quote"><div><br>Ah, sure. The functionality was committed to clang over the weekend, but placed behind a flag on Monday, but you can produce a baes address specifier with for example the following code:<br><br><font face="monospace"> void f2() {<br> }<br> __attribute__((nodebug)) void f1() {<br> }</font></div></div></div><div dir="ltr"><div class="gmail_quote"><div><font face="monospace"> void f3() {<br> }<br><br> $ clang-tot test.cpp -g -c -mllvm -use-dwarf-ranges-base-address-specifier</font><br><br>The assembly for this has a debug_ranges that looks like this:<br><br><div><font face="monospace"> .section .debug_ranges,"",@progbits</font></div><div><font face="monospace">.Ldebug_ranges0:</font></div><div><font face="monospace"> .quad -1</font></div><div><font face="monospace"> .quad .Lfunc_begin0</font></div><div><font face="monospace"> .quad .Lfunc_begin0-.Lfunc_begin0</font></div><div><font face="monospace"> .quad .Lfunc_end0-.Lfunc_begin0</font></div><div><font face="monospace"> .quad .Lfunc_begin2-.Lfunc_begin0</font></div><div><font face="monospace"> .quad .Lfunc_end2-.Lfunc_begin0</font></div><div><font face="monospace"> .quad 0</font></div><div><font face="monospace"> .quad 0</font></div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Here's my first blush at a fix for libDebugInfo - though it does rais<br>
> some questions and needs testing (is there any testing in LLVM (not lld)<br>
> for the section index API in libDebugInfo? it'd be good if there was,<br>
> maybe API level testing).<br>
<br>
I do not think we have. That looks to be my fault, I don't think I added<br>
LLVM testcase when implemented section index API.<br>
I'll check what can I do for it.<br></blockquote><div><br>I'm guessing it'll need to be a unit test - I don't imagine the section index is used by any of the LLVM tools (llvm-dwarfdump or llvm-symbolizer). /maybe/ there's a useful thing that could be exposed using SectionIndex in dwarfdump (eg: llvm-dwarfdump on an object could print the name of a section next to any addresses - which could be handy when reading ranges and the like)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
================<br>
Comment at: lib/DebugInfo/DWARF/DWARFDebugRangeList.cpp:75<br>
+ BaseAddress + RLE.EndAddress,<br>
+ BaseAddress ? SectionIndex : RLE.SectionIndex});<br>
}<br>
----------------<br>
>How should/does this differentiate between the case where the unit's<br>
>base address is actually zero? compared to when it's not present? Does<br>
>that matter? I'm not sure.<br>
<br>
So DWARF spec says:<br>
//The applicable base address of a range list entry is determined by the closest preceding base<br>
address selection entry (see below) in the same range list. If there is no such selection entry, then<br>
the applicable base address defaults to the base address of the compilation unit (see Section<br>
3.1.1).//<br>
<br>
Should `BaseAddress` and `SectionIndex` be optional then ? Then code can be like following probably:<br>
<br>
```<br>
DWARFAddressRangesVector<br>
DWARFDebugRangeList::getAbsoluteRanges(Optional<uint64_t> BaseAddress,<br>
Optional<uint64_t> BaseSectionIndex) const {<br>
DWARFAddressRangesVector Res;<br>
for (const RangeListEntry &RLE : Entries) {<br>
if (RLE.isBaseAddressSelectionEntry(AddressSize)) {<br>
BaseAddress = RLE.EndAddress;<br>
BaseSectionIndex = RLE.SectionIndex;<br>
continue;<br>
}<br>
<br>
uint64_t Start = RLE.StartAddress;<br>
uint64_t End = RLE.EndAddress;<br>
uint64_t SectionIndex = RLE.SectionIndex;<br>
if (BaseAddress) {<br>
Start += *BaseAddress;<br>
End += *BaseAddress;<br>
SectionIndex = *BaseSectionIndex;<br>
}<br>
<br>
Res.push_back({Start, End, SectionIndex });<br>
}<br>
}<br>
```<br>
<br></blockquote><div><br>Yeah, may be the right thing - at that point I'd suggest moving the BaseAddress and BaseSectionIndex into a pair/struct and wrapping that in Optional (rather than each being separately optional). <br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<a href="https://reviews.llvm.org/D36097" rel="noreferrer" target="_blank">https://reviews.llvm.org/D36097</a><br>
<br>
<br>
<br>
</blockquote></div></div></div>