[llvm] r289961 - Revert "dwarfdump: Support/process relocations on a CU's abbrev_off"

George Rimar via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 20 22:28:09 PST 2016


>The way I debugged this was to break on the line in the 'if' that my patch adds. It shows that it's adding 132 or something when run inside lld, but 0 when run in >dwarfdump on the object file itself.

>
>It looks very much like the relocation section provided to the DWARFContextInMemory in lld has adjustments applied already - it doesn't appear to be the same set of >relocations as when reading the object file directly in llvm-dwarfdump.
>
>This is why there are no CUs - they fail to parse because the abbreviations section can't be found at that offset in the input object file (I believe that's the offset in the >output instead).
>
>Rui: Does any of this sound familiar? Are relocations in input object memory buffers modified at some point?

I see the issue now. It is not a buffer was modified, reason is implementation of llvm::LoadedObjectInfo interface:
template <class ELFT>
uint64_t GdbIndexBuilder<ELFT>::getSectionLoadAddress(
    const object::SectionRef &Sec) const {
  return static_cast<const ELFSectionRef &>(Sec).getOffset();
}

I had to implement this callback, it returns section offset as an address now. That way I can later get the proper section index
in readAddressArea(size_t CurrentCU):

  for (const auto &CU : Dwarf->compile_units()) {
    DWARFAddressRangesVector Ranges;
    CU->collectAddressRanges(Ranges);
Here Ranges has [Offset + LowPC, Offset + HighPC] values then.
So I can use them to find section that range belongs to.
Otherwise Ranges is just an offset in a section and I do not know which one exactly.

I do not know the other way to do that. I tried as a different solution before implementing this one:
https://reviews.llvm.org/D25822,<https://reviews.llvm.org/D25822>? page contains more details.
It was closer to how gold solves that.

George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161221/32ae6632/attachment.html>


More information about the llvm-commits mailing list