[LLVMdev] Chaining Atoms together
shankare at codeaurora.org
Mon Nov 19 13:25:08 PST 2012
Waiting for your feedback on this.
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
> which has global and local labels.
> You are right, that the function has multiple entry points. You can
> remove the .local directive too.
> Shankar Easwaran
> On 11/15/2012 9:47 PM, Nick Kledzik wrote:
>> Let's step back. What is this use case trying to do?
>> What is:
>> .local 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?
>> 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 :-
>>> .global foo
>>> .type foo, at function
>>> jmp bar
>>> jmp fubar
>>> .global foo1
>>> .local bar
>>> .global foo2
>>> .local fubar
>>> .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
>>> 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 ?
>>> 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