<div dir="ltr"><div class="gmail_extra"><div>On Wed, Sep 4, 2013 at 3:50 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br></div><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Sep 4, 2013, at 2:32 PM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>> wrote:<br>

> On 9/4/2013 4:04 PM, Nick Kledzik wrote:<br>
>> I do think we have too many classes.<br>
> Agree.<br>
>>  I thought InputGraph was going to replace InputFiles.<br>
> Interesting idea.<br>
>>  It seems link LinkerInput could be merged into FileNode.<br>
> Agree.<br>
>><br>
>> Originally InputFiles was the abstract interface that he Resolver used to see all the inputs.  If InputGraph supported the methods  forEachInitalAtom() and searchLibraries() then we could get rid of InputFiles and have the Resolver uses InputGraph directly.<br>

> Yes, this would be nice. I will try to write a proposal in the next few days.<br>
>> What should the interface be that the Resolver uses for handling groups?<br>
> bool resolveUndefines(std::vector<File> &files) ?<br>
><br>
> This has to iterate over the files until it reaches a stable point (that no more resolution is possible).<br>
</div>It is a little more complicated.  After initial .o files are processed, there are a bunch of undefines left.  The resolver needs to start loading archive members that fulfill those undefines, but loading a member can introduce even more undefines, so it has to iterate.<br>

<br>
I think the existing searchLibraries(StringRef name, bool options..) interface almost works for InputGraph.  To support groups we just need to keep track of where in the InputGraph we currently are, so that searchLibraries() can spin in a group until no more undefs are fulfilled, then move on in the graph.<br>

<div class=""><div class="h5"><br>
-Nick<br></div></div></blockquote><div><br></div><div>The easiest way to handle this is to have the resolver do it directly. Darwin ld's behavior of looping over everything can be implemented by putting everything in an implicit group. We could make it more extensible by factoring out the searching, but I don't really see a need for that complexity.</div>
<div><br></div><div>- Michael Spencer<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">
<br>
<br>
>> On Sep 4, 2013, at 1:42 PM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>> wrote:<br>
>><br>
>>> Hi,<br>
>>><br>
>>> With the inputGraph now, lld models command line options, input files as nodes in the InputGraph called InputElements.<br>
>>><br>
>>> In the current approach, each InputElement is converted to a LinkerInput, which works if all lld deals with individual files.<br>
>>><br>
>>> Dealing with ControlNodes (Groups), have a problem with it, on how to model that as a LinkerInput.<br>
>>><br>
>>> Joerg/Me were chatting on the IRC about this and we came up with the following approach.<br>
>>><br>
>>> - LinkerInput will contain a single file(lld::File), if the node that its pointing to appears to be a FileNode<br>
>>> - LinkerInput will contain a vector(lld::Group) of files(lld::Files) , if the node that its pointing appears to be a Group<br>
>>><br>
>>> The resolver would need to be modified to consider lld::Groups in addition to lld::File.<br>
>>><br>
>>> Does this sound like the approach we want to take ?<br>
>>><br>
>>> Thanks<br>
>>><br>
>>> Shankar Easwaran<br>
>>><br>
>>> --<br>
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
>><br>
>><br>
><br>
><br>
> --<br>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
<br>
</div></div></blockquote></div><br></div></div>