[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: include/llvm/DebugInfo/DWARF/DWARFContext.h:234
   virtual StringRef getStringOffsetDWOSection() = 0;
-  virtual StringRef getRangeDWOSection() = 0;
+  virtual const DWARFSection &getRangeDWOSection() = 0;
   virtual StringRef getAddrSection() = 0;
----------------
dblaikie wrote:
> I don't think there is a ranges.dwo section, is there? The ranges section is in the .o file, always. (the DWARF5 rnglists can go in the .dwo, though)
There is no ranges.dwo in my testcase, but I had to change this API too, because I changed DWARFUnitSectionBase::parseImpl (please see DWARFUnit.h) to take const DWARFSection *RS.

I think I can't change return type for getRangeSection() without changing return type for getRangeDWOSection(),
because DWARFUnitSectionBase::parse() pushes getRangeSection(), but DWARFUnitSectionBase::parseDWO() pushes C.getRangeDWOSection() for RS.



================
Comment at: lib/DebugInfo/DWARF/DWARFDebugRangeList.cpp:25-31
+static uint64_t getAddress(DataExtractor &Data, uint32_t *Off,
+                           const RelocAddrMap &Relocs) {
+  RelocAddrMap::const_iterator AI = Relocs.find(*Off);
+  if (AI != Relocs.end())
+    return Data.getAddress(Off) + AI->second.second;
+  return Data.getAddress(Off);
+}
----------------
dblaikie wrote:
> Should/can/could this be refactored to use the same code as the case you mentioned was already in place for DW_FORM_addr (high/low pc)?
Done. There was many places that could use some helper method like getAddress() instead of inlined applying relocations to values. All of them now uses getRelocatedValue() introduced in this patch.


================
Comment at: test/DebugInfo/dwarfdump-ranges-unrelocated.s:13-15
+#   int foo1() { return 1; }  
+#   int foo2() { return 1; }  
+#   int foo3() { return 1; }  
----------------
dblaikie wrote:
> Would 2 functions (also probably simpler for them to be void and empty functions) would suffice to give the CU a DW_AT_ranges rather than high/low pc?
Yes, fixed. I added nop by myself to asm code though, thats to show that ranges are different explicitly.
I leaved single empty function to show we can dump ranges [0x0, 0x0] correctly now. 
Previous diff was not able to do that, though that was not a real problem probably, LLD anyways supposed to use 
LoadedObjectInfo::getSectionLoadAddress, so values would never be [0x0, 0x0] even for empty method, not sure about other possible users though.


https://reviews.llvm.org/D32228