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

[David Blaikie via llvm-commits]

On Thu, Apr 20, 2017 at 2:36 AM George Rimar via Phabricator <
reviews at reviews.llvm.org> wrote:

> 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.
>

I'm not sure I understand - an empty void function (void f() {}) should not
be zero-length. It would contain a single 'ret' instruction, no?


>
>
> https://reviews.llvm.org/D32228
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170420/b835e9e8/attachment.html>