[LLVMdev] [lld] Relocation reading refactoring

[Simon Atanasyan]

Hi,

Thanks for the explanation. If I understand you properly you suggest
to move relocation parsing to the class with the following interface.
Right?

Who will be user of this class? If it is still only ELFFile class,
what benefits will we get from separation of this logic?

template <class ELFT> class ELFRelocationReader {
public:
  ELFRelocationReader(.....);

  // Returns all created references.
  ReferenceRangeT getAllReferences();

  // Returns references for specified section/symbol.
  ReferenceRangeT getReferences(StringRef sectionName,
                                Elf_Sym *symbol,
                                ArrayRef<uint8_t> content);

protected:
  // Target can override these methods in the inherited class.
  virtual ELFReference<ELFT> *createReference(Elf_Rela &rel, Elf_Sym *symbol);
  virtual ELFReference<ELFT> *createReference(Elf_Rel &rel, Elf_Sym *symbol);
};

On Wed, Feb 26, 2014 at 9:42 PM, Shankar Easwaran
<shankare at codeaurora.org> wrote:
> I was thinking of having a separate class that would return a vector of
> ELFReferences when you the reader looks at a section and symbol.
>
> The class would be constructed with
> _relocationAddendReferences/_relocationReferences.
>
> Each subtarget could make use of the functionality and create a different
> type of ELFReference on a need basis.

[...]

>> What do you mean by removing relocation reading from the
>> ELFObjectFile? I considered to customize the relocation reading for
>> MIPS targets and my first idea was to factor out ELFReference creation
>> into a couple of virtual functions. The first one is for Elf_Rel, the
>> second one is for Elf_Rela. Then I planned to override these functions
>> in the MipsELFFile class. But it looks like you have more profound
>> idea. Could you share it?

-- 
Simon