[PATCH] D32228: [DWARF] - Take relocations in account when extracting ranges from .debug_ranges

[George Rimar via Phabricator via llvm-commits]

grimar added inline comments.


================
Comment at: lib/DebugInfo/DWARF/DWARFDebugRangeList.cpp:48
     }
-    if (entry.isEndOfListEntry())
+    if (entry.isEndOfListEntry(Relocs, prev_offset, AddressSize))
       break;
----------------
dblaikie wrote:
> Isn't this applying the relocation twice? The entry's Start/EndAddress are already relocated above so there shouldn't be any need to look up relocations again here, should there?
> 
> This is to handle the case where a function wasn't selected (comdat, etc) & so its base address resolves to zero by the linker - and specifically when such a function was empty anyway? (eg: "int f()" - absolutely no instructions, so begin/end are the same address)? /maybe/ that's correct/useful, but I doubt it. I'm not sure how important it is to support zero-length ranges in a range list... maybe for debugging weird DWARF output, etc.
>Isn't this applying the relocation twice? The entry's Start/EndAddress are already relocated above so there shouldn't be >any need to look up relocations again here, should there?

That not always enough, I tried to resolve corner case here. If we have asm code like one from testcase:
```
.section .text.foo1,"ax", at progbits
.Lfunc_begin0:
.Lfunc_end0:
```

Then if I dump result object file with llvm-dwarfdump, start/end address are [0x0, 0x0] both before and after relocations applied above. Because address of section is zero and relocation just adds zero size of range to end address, what leaves is as zero.
So dumping prints end marker for a entry. I think the only way to handle that is check that we do not have relocations that points to end marker [0x0, 0x0].

>This is to handle the case where a function wasn't selected (comdat, etc) & so its base address resolves to zero by the >linker - and specifically when such a function was empty anyway? (eg: "int f()" - absolutely no instructions, so begin/end >are the same address)? /maybe/ that's correct/useful, but I doubt it. 

So linker is not involved, I just noticed this when dumped testcase object. I am not sure how much is it useful in general.
(its not what I need for LLD and not intention of this patch).
Just supposed that would be more correct for llvm-dwarfdump than report <end of list> in output for a "valid" range.

>I'm not sure how important it is to support zero->length ranges in a range list... maybe for debugging weird DWARF >output, etc.

Yeah, I am not sure also. I removed that change from patch and modified testcase to have no zero length ranges for now.


https://reviews.llvm.org/D32228