[lld] Relocation reading refactoring

Hi Shankar,

Author: shankare
Date: Tue Feb 12 12:46:53 2013
New Revision: 174990

URL: http://llvm.org/viewvc/llvm-project?rev=174990&view=rev

[...]

   ELFDefinedAtom<ELFT> *createDefinedAtomAndAssignRelocations(
       StringRef symbolName, StringRef sectionName, const Elf_Sym *symbol,
       const Elf_Shdr *section, ArrayRef<uint8_t> content) {
@@ -380,6 +534,11 @@ private:
             (ri->r_offset < symbol->st_value + content.size())) {
           auto *ERef = new (_readerStorage)
               ELFReference<ELFT>(ri, ri->r_offset - symbol->st_value, nullptr);
+ // Read the addend from the section contents
+ // TODO : We should move the way lld reads relocations totally from
+ // ELFObjectFile
+ int32_t addend = *(content.data() + ri->r_offset - symbol->st_value);
+ ERef->setAddend(addend);
           _references.push_back(ERef);
         }

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?

Thanks.

Hi,

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.

Thoughts ?

Thanks

Shankar Easwaran

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);
};

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.

[...]

Hi Simon,

The subclasses for ELFFile would use it I thought.

For example if a target wants the basic logic for converting an input file to atoms, the target could just override the relocation handler to get all the references.

I would use ErrorOr<ReferenceRangeT> to return any errors from relocation processing.

Thanks

Shankar Easwaran

Hi Shankar,

I almost implement ELFRelocationReader but still not completely sure
that this is a right direction. Suppose somebody wants to override
creation of the `ELFReference` object from the `Elf_Rela` or `Elf_Rel`
record. Let's consider two implementations A and B:

A:

We could stick to option A and implement or move to option B need be.

Hi Shankar,

I've implemented the option "A" at r203408:
http://llvm.org/viewvc/llvm-project?rev=203408&view=rev

We could stick to option A and implement or move to option B need be.

Sent from my iPhone

[...]

LGTM. Thanks for the info.