Hi, Attached is the pdf of the operation to make things easier to read. Thanks Shankar Easwaran On 9/20/2013 7:04 PM, Shankar Easwaran wrote:> My email client spoilt the whole email, will create a pdf and send it. > > On 9/20/2013 7:00 PM, Shankar Easwaran wrote: >> Hi Nick, >> >> On 9/20/2013 5:59 PM, Nick Kledzik wrote: >>> On Sep 20, 2013, at 3:42 PM, Shankar Easwaran >>> <shankare at codeaurora.org> wrote: >>>> nextFile could pass the current resolver state at the time when its >>>> called, the linkingcontext can return the next file to be processed >>>> as below :- >>>> >>>> nextFile(currentResolverState) :- >>>> >>>> a) Returns the next file if the current node is not a group node >>>> b) Returns the next file in the group node, if the current node is >>>> a group node and the resolver state states undefined /weak / shared >>>> library atoms were added. >>>> c) Returns the start file in the group node, if the resolver state >>>> states undefined/weak/shared library atoms were added >>>> d) If the state is unchanged, no symbols were added exit the group >>>> and move to the next node. >>> What causes the Resolver state to change? I understand the state >>> of "there are undefines remaining", but the "something was added" is >>> a transient state. Each last file, changes it. >> Sorry for the long mail. This should explain things better. >> >> Here is a example with a state diagram on how the above proposal >> works. The main idea is to keep a running state of the resolver and >> the capturing the resolver state of each input file in the group by >> the linkingcontext. >> >> lld -flavor gnu main.o thread.o --start-group libc.a libpthread.a >> --end-group function.o >> >> main.o has atoms >> ------------------------ >> main (defined) >> printf(undefined) >> fn(undefined) >> >> thread.o has atoms >> ----------------------------- >> pthread_create (undefined) >> >> libc.a(printf.o) has atoms >> ------------------------------------ >> printf(defined) >> >> libc.a(exit.o) has atoms >> ---------------------------------- >> exit(defined) >> >> libpthread.a has atoms >> --------------------------------- >> pthread_create(defined) >> exit(undefined) >> >> function.o has atoms >> ------------------------------- >> fn(defined) >> >> >> State diagram with time information >> >> Resolver resolverState Context(nextFile) >> -------------- ------------------ ---------------- >> resolverState = initialState >> nextFile(resolverState) initialState >> ELFContextState=processingFileNode, return a.o >> resolverState = nochange >> process(a.o) >> state = definedatoms/undefinedatoms (reason: main/printf) >> nextFile(resolverState) definedAtoms/undefinedAtoms >> ELFContextState=processingFileNode, return b.o >> resolverState = nochange >> process(b.o) >> state = undefinedatoms(reason: pthread_create) >> nextFile(resolverState) undefinedAtoms >> ELFContextState=processingGroupNode, return libc.a >> resolverState=nochange >> process(libc.a) >> process(printf.o) >> state = definedatom (reason: printf) >> nextFile(resolverState) definedAtoms >> ELFContextState=processingGroupNode, state[libc.a]=definedAtoms, >> return libpthread.a >> resolverState=nochange >> process(libpthread.a) >> process(pthread.o) >> state = definedatom/undefinedatoms (reason: pthread_create/exit) >> nextFile(resolverState) definedAtoms/undefinedatoms >> ELFContextState=processingGroupNode, >> state[libpthread.a]=definedAtoms|undefinedAtoms, return libc.a >> (returns the first file in the group) >> >> *LinkingContext would exit the GroupNode only if the state of each >> file in the group is unchanged, or has only definedAtoms.* >> ///LinkingContext here, finds that libc.a has definedAtoms, whereas >> libpthread.a has undefinedAtoms, so traverses the group back./* >> >> *resolverState=nochange >> process(libc.a) >> process(exit.o) >> state = definedatom (reason: exit) >> nextfile(resolverState) definedAtoms >> ELFContextState=processingGroupNode, state[libc.a] = definedAtoms, >> return libpthread.a >> resolverState=nochange >> process(libc.a) >> state = nochange >> nextfile(resolverState) nochange ELFContextState=processingGroupNode, >> state[libpthread.a] = nochange, >> >> / LinkingContext //finds >> that libc.a state has "definedAtoms", and libpthread.a has >> "nochange", so exits the group./* >> >> *resolverState=nochange >> process(function.o) >> state = definedatom (reason: fn) >> >> Exit. >> >> Thanks >> >> Shankar Easwaran >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130920/31ab1ef1/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: design.pdf Type: application/pdf Size: 45618 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130920/31ab1ef1/attachment.pdf>
Hi Nick, Read this along with this example extract: ld -flavor gnu main.o thread.o --start-group libc.a libpthread.a --end-group function.o main.o has atoms ------------------------ main (defined) printf(undefined) fn(undefined) thread.o has atoms ----------------------------- pthread_create (undefined) libc.a(printf.o) has atoms ------------------------------------ printf(defined) libc.a(exit.o) has atoms ---------------------------------- exit(defined) libpthread.a has atoms --------------------------------- pthread_create(defined) exit(undefined) function.o has atoms ------------------------------- fn(defined) Thanks Shankar Easwaran On 9/20/2013 7:42 PM, Shankar Easwaran wrote:> Hi, > > Attached is the pdf of the operation to make things easier to read. > > Thanks > > Shankar Easwaran > > On 9/20/2013 7:04 PM, Shankar Easwaran wrote: >> My email client spoilt the whole email, will create a pdf and send it. >> >> On 9/20/2013 7:00 PM, Shankar Easwaran wrote: >>> Hi Nick, >>> >>> On 9/20/2013 5:59 PM, Nick Kledzik wrote: >>>> On Sep 20, 2013, at 3:42 PM, Shankar Easwaran >>>> <shankare at codeaurora.org> wrote: >>>>> nextFile could pass the current resolver state at the time when >>>>> its called, the linkingcontext can return the next file to be >>>>> processed as below :- >>>>> >>>>> nextFile(currentResolverState) :- >>>>> >>>>> a) Returns the next file if the current node is not a group node >>>>> b) Returns the next file in the group node, if the current node is >>>>> a group node and the resolver state states undefined /weak / >>>>> shared library atoms were added. >>>>> c) Returns the start file in the group node, if the resolver state >>>>> states undefined/weak/shared library atoms were added >>>>> d) If the state is unchanged, no symbols were added exit the group >>>>> and move to the next node. >>>> What causes the Resolver state to change? I understand the state >>>> of "there are undefines remaining", but the "something was added" >>>> is a transient state. Each last file, changes it. >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >>-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130920/0454c886/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: design.pdf Type: application/pdf Size: 45618 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130920/0454c886/attachment.pdf>
Shankar,
I think your proposal and mine are pretty much the same. The difference is
passing back info to the InputGraph as a parameter in nextFile() vs as a
separate method call. My original draft email had a parameter in nextFile(),
but it seemed a little confusing because the information was referring to the
previous file. That is, if the current resolver state has newDefinedAtoms, that
really means the last file (returned by nextFile()) caused new atoms to be
added.
In your ResolverState you have bits for all the kinds of atoms added. Is all
that needed? I think all the InputGraph needs to know is if the last file was
used. A group is scanned repeatedly until there is one complete pass in which
no new files were used.
Also, is nextFile() going to be in InputGraph and directly accessed by the
Resolver? Or is nextFile in LinkingContext (which forwards it to the
InputGraph)? I assume the later.
Currently, the Resolver has buildInitialAtomList() and resolveUndefines() which
matches the way darwin links. I assume part of this change is to unify those
two methods by just have one loop that uses nextFile().
Given that nextFile() is basically an iteration mechanism, perhaps we can make
it conform to C++11 iterators. The one issue is the feedback of whether the
file was used or not. A separate notifyFileAddedContent() method (instead of a
parameter to nextFile()) could fix that. And if Resolver::doFile() called
linkingContext.notifyFileAddedContent() for every file used (even object files),
then the Resolver algorithm would look like:
for (File *file : linkingContext) {
if (file.kind() == object) {
// add
}
else if (file.kind() == archive) {
if (resolvesSomeUndefs(file)) {
// add
}
}
}
-Nick
On Sep 20, 2013, at 5:56 PM, Shankar Easwaran <shankare at codeaurora.org>
wrote:> Hi Nick,
>
> Read this along with this example extract:
>
> ld -flavor gnu main.o thread.o --start-group libc.a libpthread.a
--end-group function.o
>
> main.o has atoms
> ------------------------
> main (defined)
> printf(undefined)
> fn(undefined)
>
> thread.o has atoms
> -----------------------------
> pthread_create (undefined)
>
> libc.a(printf.o) has atoms
> ------------------------------------
> printf(defined)
>
> libc.a(exit.o) has atoms
> ----------------------------------
> exit(defined)
>
> libpthread.a has atoms
> ---------------------------------
> pthread_create(defined)
> exit(undefined)
>
> function.o has atoms
> -------------------------------
> fn(defined)
>
> Thanks
>
> Shankar Easwaran
>
> On 9/20/2013 7:42 PM, Shankar Easwaran wrote:
>> Hi,
>>
>> Attached is the pdf of the operation to make things easier to read.
>>
>> Thanks
>>
>> Shankar Easwaran
>>
>> On 9/20/2013 7:04 PM, Shankar Easwaran wrote:
>>> My email client spoilt the whole email, will create a pdf and send
it.
>>>
>>> On 9/20/2013 7:00 PM, Shankar Easwaran wrote:
>>>> Hi Nick,
>>>>
>>>> On 9/20/2013 5:59 PM, Nick Kledzik wrote:
>>>>> On Sep 20, 2013, at 3:42 PM, Shankar Easwaran <shankare
at codeaurora.org> wrote:
>>>>>> nextFile could pass the current resolver state at the
time when its called, the linkingcontext can return the next file to be
processed as below :-
>>>>>>
>>>>>> nextFile(currentResolverState) :-
>>>>>>
>>>>>> a) Returns the next file if the current node is not a
group node
>>>>>> b) Returns the next file in the group node, if the
current node is a group node and the resolver state states undefined /weak /
shared library atoms were added.
>>>>>> c) Returns the start file in the group node, if the
resolver state states undefined/weak/shared library atoms were added
>>>>>> d) If the state is unchanged, no symbols were added
exit the group and move to the next node.
>>>>> What causes the Resolver state to change? I understand
the state of “there are undefines remaining”, but the “something was added” is a
transient state. Each last file, changes it.
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by the Linux Foundation
> <design.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130920/61bf3c17/attachment.html>