<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Sep 4, 2013, at 9:28 PM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>> wrote:<br><div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="moz-cite-prefix">Hi Nick,<br><br>These are the below modifications needed in lld to start processing groups :-<br><br>1) LinkerInput would be moved to FileNode that contains the following functions<br> - getBuffer<br> - takeBuffer<br> - getPath<br><br>2) The driver will process the vector of InputElements and call<span class="Apple-converted-space"> </span><i><b>process<span class="Apple-converted-space"> </span></b></i>on each of them.<br> process() would create a lld::File object within the InputElement if its a FileNode<br> process() would create a vector of lld::File objects within the InputElement if its a ControlNode<br><br>3) The resolver will not process each file but it would process InputElements and would do the following :-<br> 3.1 ) if the InputElement corresponds to a fileNode, the resolver will call in<br> inputElement->processAtoms(*this) and marks the InputElement as already processed.<br> <b><span class="Apple-converted-space"> </span>This would essentially call resolver.processFile(_currentFile)</b><br><br> 3.2) If the inputElement corresponds to a GroupNode, the resolver will call inputElement->processAtom(*this) on<span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><b>This</b><span class="Apple-converted-space"> </span><b>would essentiall call resolver.processGroup(std::vector<Files>), the vector of files is what makes it in the current group</b><br><br>4) InputFiles would be removed<br>5) LinkerInput would be removed<br>6) Functions that are unused forEachInitialAtom etc<br><br><u><b>Issues</b></u><b><br><br></b>This will essentially break the Darwin model thats in lld, as the current functionalities processes all the object files and only then processes<br>archive files.<span class="Apple-converted-space"> </span><br><br>Can we control by using a resolution policy ? which is a set of boolean flags to control the resolution behavior ? Do you have any other approach ?<br></div></div></blockquote><div><br></div><div>The way darwin works with the current scheme is that the files are added to InputFiles in command line order, then forEachInitialAtom() walks the whole list but only operates on the non-library (i.e. object files) and searchLibraries() only operates on library files. </div><div><br></div><div>If we have the Resolver walk the graph, then either:</div><div>1) We need some option for darwin and gnu to work differently, or </div><div>2) Have the darwin driver construct the graph with all libraries in one group at the end. As long as that is straight forward to do, it seems simpler and also captures the darwin difference that all libraries are always repeatedly searched.</div><div><br></div><div>-Nick</div><div><br></div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="moz-cite-prefix"><br><u><b>Questions</b></u><br><br>1) There might be other types of control nodes, what would we need to do, can the resolver be controlled by each flavor ?<br><br>Thanks<br><br>Shankar Easwaran<br><br><br>On 9/4/2013 5:50 PM, Nick Kledzik wrote:<br></div><blockquote cite="mid:D9BEF8BB-74FD-4795-A2A0-A71BC0A3874F@apple.com" type="cite"><pre wrap="">On Sep 4, 2013, at 2:32 PM, Shankar Easwaran <a class="moz-txt-link-rfc2396E" href="mailto:shankare@codeaurora.org"><shankare@codeaurora.org></a> wrote:
</pre><blockquote type="cite"><pre wrap="">On 9/4/2013 4:04 PM, Nick Kledzik wrote:
</pre><blockquote type="cite"><pre wrap="">I do think we have too many classes.
</pre></blockquote><pre wrap="">Agree.
</pre><blockquote type="cite"><pre wrap=""> I thought InputGraph was going to replace InputFiles.
</pre></blockquote><pre wrap="">Interesting idea.
</pre><blockquote type="cite"><pre wrap=""> It seems link LinkerInput could be merged into FileNode.
</pre></blockquote><pre wrap="">Agree.
</pre><blockquote type="cite"><pre wrap="">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.
</pre></blockquote><pre wrap="">Yes, this would be nice. I will try to write a proposal in the next few days.
</pre><blockquote type="cite"><pre wrap="">What should the interface be that the Resolver uses for handling groups?
</pre></blockquote><pre wrap="">bool resolveUndefines(std::vector<File> &files) ?
This has to iterate over the files until it reaches a stable point (that no more resolution is possible).
</pre></blockquote><pre wrap="">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.
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.
-Nick
</pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">On Sep 4, 2013, at 1:42 PM, Shankar Easwaran <a class="moz-txt-link-rfc2396E" href="mailto:shankare@codeaurora.org"><shankare@codeaurora.org></a> wrote:
</pre><blockquote type="cite"><pre wrap="">Hi,
With the inputGraph now, lld models command line options, input files as nodes in the InputGraph called InputElements.
In the current approach, each InputElement is converted to a LinkerInput, which works if all lld deals with individual files.
Dealing with ControlNodes (Groups), have a problem with it, on how to model that as a LinkerInput.
Joerg/Me were chatting on the IRC about this and we came up with the following approach.
- LinkerInput will contain a single file(lld::File), if the node that its pointing to appears to be a FileNode
- LinkerInput will contain a vector(lld::Group) of files(lld::Files) , if the node that its pointing appears to be a Group
The resolver would need to be modified to consider lld::Groups in addition to lld::File.
Does this sound like the approach we want to take ?
Thanks
Shankar Easwaran
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
</pre></blockquote><pre wrap=""></pre></blockquote><pre wrap="">--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
</pre></blockquote><pre wrap="">
</pre></blockquote><br><br><pre class="moz-signature" cols="72">--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation</pre></div></blockquote></div><br></body></html>