[LLVMdev] LLD input graph handling proposal

[Nick Kledzik]

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>