llvm dev - Feb 2014 - [LLVMdev] [lld] Relocation reading refactoring

Hi Shankar,

On Tue, Feb 12, 2013 at 10:46 PM, Shankar Easwaran
<shankare at codeaurora.org> wrote:
> 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.

--
Simon

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

On 2/26/2014 4:56 AM, Simon Atanasyan wrote:
> Hi Shankar,
>
> On Tue, Feb 12, 2013 at 10:46 PM, Shankar Easwaran
> <shankare at codeaurora.org> wrote:
>> 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.
>
> --
> Simon
>
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

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