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

[David Blaikie via llvm-commits]

Seems we have a few choices:

Say that getSectionLoadAddress should return 0 for all debug info sections
Change libDebugInfo/DWARF to not query getSectionLoadAddress for debug info
sections (so they're effectively zero)
Change DWARFDebugAbbrev::extract to take into account the base address of
the section when parsing/building the table.

I suspect 1 or 2 is better, and probably 2. But that's also a bit
inconvenient having to do more special case logic about how we apply/create
relocations - an already pretty complicated part of the DWARF parsing code,
I think.

(+ Lang, Keno, and Eric - involved in adding this getSectionLoadAddress
support in the first place. I'm guessing for the JIT use case it wouldn't
have ever had a load address for a debug info section - just for the code
sections?)

On Tue, Dec 20, 2016 at 10:28 PM George Rimar <grimar at accesssoftek.com>
wrote:

> >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/c4e287fb/attachment.html>