[LLVMdev] Chaining Atoms together

[Shankar Easwaran]

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