[llvm-commits] [LLD] Patch to tie Atoms in a section together

[Shankar Easwaran]

Hi Nick,

I had a chat with Michael and I will resubmit the patch for review with 
the below changes :-

1) Add Follow on reference functionality in Core
2) Use the follow on reference in ReaderELF
3) Change the testcase

Thanks

Shankar Easwaran

On 10/25/2012 6:57 AM, Shankar Easwaran wrote:
> On 10/24/2012 8:59 PM, Shankar Easwaran wrote:
>> On 10/24/2012 8:44 PM, Nick Kledzik wrote:
>>> On Oct 24, 2012, at 6:25 PM, Shankar Easwaran wrote:
>>>
>>>>>>> This requires some more explanation.  Are you trying to prevent 
>>>>>>> them from ever being removed?  Or they can only be removed is 
>>>>>>> everything is the section is removed?  If the former, the 
>>>>>>> dead-strip setting would do the same.  If the latter, if you are 
>>>>>>> trying to keep the order of the functions, do you want something 
>>>>>>> stronger which says they cannot be reordered too? The "none" 
>>>>>>> reference just keeps them alive.
>>>>>> I am trying to do the latter, they can only be removed only if 
>>>>>> the section is removed. I couldnt follow why the 'none' reference 
>>>>>> would not keep the functions together though.
>>>>> If someone were to write a Pass which re-ordered functions based.  
>>>>> How would the pass know to not re-order those functions?
>>>>>
>>>> I will go ahead and create a reference from the current symbol to 
>>>> the next symbol too, so that they dont get reordered.
>>> Shankar,
>>>
>>> I think you are missing my point.  Garbage collection (aka dead 
>>> stripping) and atom re-ordering are different things. They both will 
>>> cause problems with assembly code written assuming only whole 
>>> sections will copied to output files. But, adding a reference only 
>>> prevents garbage collection.  It does not stop re-ordering of atoms.
>>>
>>> To stop re-ordering of atoms, the darwin linker uses a special 
>>> reference  kind called a follow-on.  The re-ordering pass knows it 
>>> cannot move an atom relative to another atom that has a follow-on 
>>> reference to it.   More specifically, if A has a follow-on reference 
>>> to B, then atom B must immediately follow (be laid out) after atom A.
>>>
>>> Currently in lld, all References are platform specific.  We don't 
>>> yet have a way that generic Passes can infer meaning from reference 
>>> kind
>>>
>> Hi Nick,
>>
>> Thanks for your reply.
>>
>> Currently the writer creates the output ELF file in file order and in 
>> the order that atoms appeared in the input file(sorted by ordinality).
>>
>> My thought is we can use the 'none' reference as a follow on 
>> reference as it is in the MachO linker so that we know what atoms 
>> come next. Will this not be true ? Do you see a possibility of a 
>> relocation type 'none' being used elsewhere too.
>>
>> Let me know your thoughts.
>>
>> Thanks
>>
>> Shankar Easwaran
>>
>>
> Hi Nick,
>
> I wanted to understand the design choice in the darwin linker, that
>
> 1) Was the follow-on reference added in the relocation entries for 
> each Atom ?
> 2) Why wasnt it added as a private member for each Atom, If there is a 
> follow on reference, Each atom could contain a reference to another 
> atom in the follow on member for that Atom.
>      Advantages are
>
>      a) When the writer tries to write the Atoms, it would write all 
> atoms that follow in order, if it contains a follow on Atom
>      b) This is platform neutral
>      c) Easy to resolve Atoms and support Atom groups
>
> Let me know your thoughts on either approaches with the current lld 
> model. I will change the code accordingly.
>
> Thanks
>
> Shankar Easwaran
>
>


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