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

[Shankar Easwaran]

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