[PATCH] D35004: [DWARF] - Add API to allow DWARFContextInMemory to delegate relocations handling to client.

[George Rimar via llvm-commits]

>I wonder if it would not be better to split DWARFContextInMemory in two.
>
>DWARFContextInMemory would have no idea how to get section contents and
>relocations. It would deffer that to a helper object. The
>DWARFContextInMemory constructor would do nothing.
>
>In llvm we would have a helper implementation that looks just like the
>current DWARFContextInMemory constructor:
>
>* Walk all sections.
>* Decompress if compressed.
>* Parse relocations into maps.
>
>In lld we could have a very different implementation
>
>* Don't walk the sections. We already did that.
>* Don't decompress, we already did that.

This reminds me about second constructor of DwarfContextInMemory:
https://github.com/llvm-mirror/llvm/blob/master/lib/DebugInfo/DWARF/DWARFContext.cpp#L1077

Assumed it takes user defined list of already relocated, decompressed sections and do nothing else.

>* Don't parse relocations early.
>
>The last point is because lld does a very simple in order walk over the
>data. I would be surprised if it is not more efficient to walk the
>relocations is lockstep instead of having a full map.
>
>Cheers,
>Rafael

So it seems we can use second constructor and feed parsers with decompressed sections we already have.
That solves 1, 2 from your list.

Then looks we need to change the way of how DWARF parsers work with relocations in this case.
When second constructor is used, RelocAddrMap remains empty and proper values are taken from
section's data, because it is currently assumed data is relocated. In out case LLD will provide non-relocated
content.

Currently RelocAddrMap is a part of DWARFSection class. Instead of that looks
we may introduce some helper. Which should be able to return relocation value for section
by relocation offset. Default implementation will still use RelocAddrMap, and LLD specific can do whatever
it wants on its side.

I am going to suspend D35004 and D35005 for now (right ?) and try to prepare some patch to 
rework how parsers handle the relocations for start. Sound fine ?

George.