[LLVMdev] Chaining Atoms together

[Nick Kledzik]

On Nov 19, 2012, at 1:25 PM, Shankar Easwaran wrote:
> Hi Nick,
> 
> Waiting for your feedback on this.
It seems the crux of the issue is that in ELF, an assembly programmer can put any random value into the .size directive and you want to faithfully reproduce that st_size value in the final executable.  

Given that the atom model already has a "size" for atoms and for any compiler generated code that size will be the same as the st_size, I don't think we should add a new kind of "size" attribute to the atom model.  It would only be used by odd hand written ELF assembly files.  I think a better way to handle extra info like this is to have the ELF Reader add a new Reference to DefinedAtoms if and only if the st_size does not match the computed atom size.  The Reference has no target and some special kind value known only to the ELF Reader and Writer.  The ELF Writer normally sets the st_size field based on the atom size, but it the atom contains one of these special Refererences, the st_size comes from the Reference addend.


-Nick


> 
> 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
>