[LLVMdev] Chaining Atoms together

[Shankar Easwaran]

Ping ?

On 11/19/2012 3:25 PM, Shankar Easwaran wrote:
> 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