[LLVMdev] Chaining Atoms together

Shankar Easwaran shankare at codeaurora.org
Mon Nov 19 13:25:08 PST 2012

Hi Nick,

Waiting for your feedback on this.


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

More information about the llvm-dev mailing list