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