[LLVMdev] Chaining Atoms together

[Shankar Easwaran]

Hi Nick,

Waiting for your feedback on this.

Thanks

Shankar Easwaran

On 11/16/2012 10:03 AM, Shankar Easwaran wrote:
> Hi Nick,
>
> Thanks for your reply.
>
> The usecase here is just trying to construct a valid ELF. The lld 
> linker needs to handle all sorts of code written in assembly as well 
> as 'C'. The usecase is just one example of it.
>
> I have also seen similiar code in 
> http://lxr.free-electrons.com/source/arch/powerpc/kernel/head_32.S?a=powerpc 
> which has global and local labels.
>
> You are right, that the function has multiple entry points. You can 
> remove the .local directive too.
>
> Thanks
>
> Shankar Easwaran
>
> On 11/15/2012 9:47 PM, Nick Kledzik wrote:
>> Shankar,
>>
>> Let's step back.  What is this use case trying to do?
>>
>> What is:
>>     .local bar
>> bar:
>>
>> I have not seen the .local directive.  Symbols are local to the 
>> assembler by default and need a .global directive to make it to the 
>> .o file.  Local symbols also usually start with ".L"
>>
>> Why does only "foo" have the .type and .size directives?  Is the goal 
>> here to have one "function" with multiple entry points?
>>
>> -Nick
>>
>>
>> On Nov 15, 2012, at 6:50 PM, Shankar Easwaran wrote:
>>> Hi Nick,
>>>
>>> Below is an use case where we need all atoms within a section be 
>>> chained together.
>>>
>>> The usecase that we have currently is when a function foo which has 
>>> a mix of local/global symbols for example :-
>>>
>>>   .text
>>>   .global foo
>>>   .type foo, at function
>>> foo:
>>>   jmp bar
>>>   jmp fubar
>>>   ret
>>>   .global foo1
>>> foo1:
>>>   ret
>>>   .local bar
>>> bar:
>>>   ret
>>>   .global foo2
>>> foo2:
>>>   ret
>>>   .local fubar
>>> fubar:
>>>   ret
>>>   .size foo,.-foo
>>>
>>> When the object file is read by lld, the ELF Reader converts the 
>>> .text section into the following defined atoms :-
>>> a) foo
>>> b) foo1
>>> c) bar
>>> d) foo2
>>> e) fubar
>>>
>>> The atoms have to appear in the same order as the assembler already 
>>> has fixed the relocations in the ".text" section. This is done by 
>>> having the Reader to chain all the atoms together in the .text section.
>>>
>>> In addition to the above, we need a way so that the size information 
>>> of the atom is appropriately emitted by the linker in the final 
>>> executable / object file. When we read the object file, the size 
>>> information of the symbol that was there
>>> in the symbol table needs to be preserved until the linker writes 
>>> the binary.
>>>
>>> Referring to the above example we see that the function atom "foo", 
>>> has contents set to
>>>
>>> jmp bar
>>> jmp foobar
>>> ret
>>>
>>> The definedAtom "foo" gets created with the above contents and sets 
>>> the atom size to be the size of whatever data that has been read. In 
>>> this example, the Atom size of "foo" becomes 5 bytes.
>>> But when the Atom "foo" gets written by the linker it needs to be 
>>> set to the size thats specified in the symbol table(9 bytes).
>>>
>>> To fix this, What is needed is
>>>
>>> a) A field in the NativeDefinedAtomIvarsV1 datastructure to hold the 
>>> symbol size information that was present in the symbol table.
>>> b) A field in the DefinedAtom class to store the symbol size 
>>> information (needed back for the NativeReader to construct the 
>>> DefinedAtom object appropriately)
>>>
>>> Can I go ahead and do the modifications to the 
>>> NativeDefinedAtomsIvarsV1 and the DefinedAtom class to store this 
>>> additional attribute ?
>>>
>>> Thanks
>>>
>>> Shankar Easwaran
>>>
>>> -- 
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
>>> hosted by the Linux Foundation
>>>
>>
>>
>
>


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