<meta http-equiv="content-type" content="text/html; charset=utf-8"><div>We could stick to option A and implement or move to option B need be. <br><br>Sent from my iPhone</div><div><br>On Mar 6, 2014, at 1:58, "Simon Atanasyan-2 [via LLVM]" <<a href="/user/SendEmail.jtp?type=node&node=66568&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>> wrote:<br><br></div><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' type="cite"><div>

        Hi Shankar,

<br><br>I almost implement ELFRelocationReader but still not completely sure

<br>that this is a right direction. Suppose somebody wants to override

<br>creation of the `ELFReference` object from the `Elf_Rela` or `Elf_Rel`

<br>record. Let's consider two implementations A and B:

<br><br>A:

<br>=====

<br>1. Factor out `ELFReference` creation from

<br>`createDefinedAtomAndAssignRelocations` into a couple of virtual

<br>functions with the following signature:

<br><br>ELFReference<ELFT> *

<br>createRelocationReference(const Elf_Sym &symbol, const Elf_Rela &rai);

<br><br>ELFReference<ELFT> *

<br>createRelocationReference(const Elf_Sym &symbol, const Elf_Rel &ri,

<br>                          ArrayRef<uint8_t> content);

2. Override one or both these methods in the <target name>ELFFile class.

<br><br>B:

<br>=====

<br>1. Create new class `ELFRelocationReader` and factor out

`ELFReference` creation into the methods of this class.

<br>2. Add new virtual function `createRelocationReader` to the `ELFFile`

to create an instance of the `ELFRelocationReader`.

<br>3. Subclass `ELFRelocationReader` and implement a target specific

relocation reading.

<br>4. Override `ELFFile::createRelocationReader` to create

`ELFRelocationReader` subclass.

<br><br>In both implementations we just move some portion of code from one

<br>place to another. We do not need to reuse the relocation reading

<br>functionality somewhere else. But the implementation "A" requires much

<br>less modifications and does not introduce any new entities. So from my

<br>point of view both approaches provide the same result but the

<br>implementation "B" much more wordy. Will we get any benefits if

<br>implement option "B"?

Thanks.

<br><br>On Thu, Feb 27, 2014 at 2:33 AM, Shankar Easwaran

<br><<a href="/user/SendEmail.jtp?type=node&node=66564&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>> wrote:

> The subclasses for ELFFile would use it I thought.

<br>>

<br>> For example if a target wants the basic logic for converting an input file

<br>> to atoms, the target could just override the relocation handler to get all

<br>> the references.

<br><br>[...]

<br><br>> On 2/26/2014 3:16 PM, Simon Atanasyan wrote:

<br><br>[...]

<br><div class="shrinkable-quote"><div class='shrinkable-quote'><br>>> Who will be user of this class? If it is still only ELFFile class,

>> what benefits will we get from separation of this logic?

<br>>>

<br>>> template <class ELFT> class ELFRelocationReader {

<br>>> public:

<br>>>    ELFRelocationReader(.....);

<br>>>

<br>>>    // Returns all created references.

<br>>>    ReferenceRangeT getAllReferences();

<br>>>

>>    // Returns references for specified section/symbol.

<br>>>    ReferenceRangeT getReferences(StringRef sectionName,

<br>>>                                  Elf_Sym *symbol,

<br>>>                                  ArrayRef<uint8_t> content);

<br>>>

<br>>> protected:

>>    // Target can override these methods in the inherited class.

<br>>>    virtual ELFReference<ELFT> *createReference(Elf_Rela &rel, Elf_Sym

<br>>> *symbol);

<br>>>    virtual ELFReference<ELFT> *createReference(Elf_Rel &rel, Elf_Sym

<br>>> *symbol);

<br>>> };

<br>>>

<br>>> On Wed, Feb 26, 2014 at 9:42 PM, Shankar Easwaran

<br>>> <<a href="/user/SendEmail.jtp?type=node&node=66564&i=1" target="_top" rel="nofollow" link="external">[hidden email]</a>> wrote:

<br>>>>

<br>>>> 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.

<br>>>>

<br>>>> The class would be constructed with

<br>>>> _relocationAddendReferences/_relocationReferences.

<br>>>>

<br>>>> Each subtarget could make use of the functionality and create a different

>>> type of ELFReference on a need basis.

<br>>>

<br>>> [...]

<br>>>

<br>>>>> What do you mean by removing relocation reading from the

<br>>>>> ELFObjectFile? I considered to customize the relocation reading for

<br>>>>> MIPS targets and my first idea was to factor out ELFReference creation

<br>>>>> into a couple of virtual functions. The first one is for Elf_Rel, the

<br>>>>> second one is for Elf_Rela. Then I planned to override these functions

<br>>>>> in the MipsELFFile class. But it looks like you have more profound

>>>> idea. Could you share it?

</div></div>-- 

<br>Simon

<br>_______________________________________________

<br>LLVM Developers mailing list

<br><a href="/user/SendEmail.jtp?type=node&node=66564&i=2" target="_top" rel="nofollow" link="external">[hidden email]</a>         <a href="http://llvm.cs.uiuc.edu" target="_top" rel="nofollow" link="external">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_top" rel="nofollow" link="external">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>

        <br>

        <br>

        <hr noshade="noshade" size="1" color="#cccccc">

        <div style="color:#444; font: 12px tahoma,geneva,helvetica,arial,sans-serif;">

                <div style="font-weight:bold">If you reply to this email, your message will be added to the discussion below:</div>

                <a href="http://llvm.1065342.n5.nabble.com/lld-Relocation-reading-refactoring-tp66310p66564.html" target="_top" rel="nofollow" link="external">http://llvm.1065342.n5.nabble.com/lld-Relocation-reading-refactoring-tp66310p66564.html</a>

        </div>

        <div style="color:#666; font: 11px tahoma,geneva,helvetica,arial,sans-serif;margin-top:.4em;line-height:1.5em">

                To start a new topic under LLVM - Dev, email <a href="/user/SendEmail.jtp?type=node&node=66568&i=1" target="_top" rel="nofollow" link="external">[hidden email]</a> <br>

                To unsubscribe from LLVM - Dev, <a href="" target="_top" rel="nofollow" link="external">click here</a>.<br>

                <a href="http://llvm.1065342.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml" rel="nofollow" style="font:9px serif" target="_top" link="external">NAML</a>

        </div></div></blockquote>

<br/><hr align="left" width="300" />

View this message in context: <a href="http://llvm.1065342.n5.nabble.com/lld-Relocation-reading-refactoring-tp66310p66568.html">Re: [lld] Relocation reading refactoring</a><br/>

Sent from the <a href="http://llvm.1065342.n5.nabble.com/LLVM-Dev-f3.html">LLVM - Dev mailing list archive</a> at Nabble.com.<br/>