<div dir="ltr">Let me do the actual rewriting stuff. I believe I have a good track on cleaning things up in LLD than anyone else in the project lately and I'd like to take this too as this is important.<div><br></div><div>It looks like we agreed on the idea that we should move features from InputGraph to the Resolver. Is this correct? It seems the reason to add the Tag class is to achieve that idea.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 31, 2014 at 4:31 PM, Michael Spencer <span dir="ltr"><<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Oct 30, 2014 at 10:33 PM, Nick Kledzik <<a href="mailto:kledzik@apple.com">kledzik@apple.com</a>> wrote:<br>
> I don’t understand these tags.  Seems like the [Start|End]Group are<br>
> *between* FileLocators (just like on the command line).  What is the Prefer*<br>
> tag?  Does it apply just to that FileLocator, or all follow on ones?<br>
><br>
> What about other attributes like whole-archive?<br>
<br>
</span>They are in between FileLocators. The resolver tracks them.<br>
whole-archive would also be a tag.<br>
<span class=""><br>
> Why can’t the driver pre-resolve all paths so that FileLocator just deals<br>
> with full paths and not searching?<br>
<br>
</span>Because some paths come while reading inputs. Such as linker scripts<br>
and #pragma lib.<br>
<span class=""><br>
> I don’t see how mach-o linking will work. The driver needs to take many<br>
> passes over the whole list.  The first pass just picks out object files.<br>
> The remaining passes only pick out libraries and it repeats until nothing<br>
> new is loaded.<br>
<br>
</span>The resolver will have a specific mode for Darwin linker semantics.<br>
<span class=""><br>
> When does parsing happen?  When would it not happen (as it does today)<br>
> before the Resolver is even run?<br>
<br>
</span>Parsing generally happens before the resolver is run, but sometimes<br>
the resolver will request an object from an archive that has not been<br>
parsed before. At this point it should parse it.<br>
<span class=""><br>
> This is where it gets interesting. The ability to have multiple “files” in<br>
> one yaml disk file is great for writing one-file-test-cases.  But now every<br>
> disk file may contain multiple logical lld::Files some of which may be<br>
> relocatable or library files.  The Resolver just needs an iterator over the<br>
> lld::Files, but the driver is providing the disk files.<br>
<br>
</span>Yes, this is an issue. It may make sense to have FileLocator also be<br>
able to represent a lld::File directly.<br>
<span class=""><br>
><br>
><br>
> I still kinda of like my idea of the LinkingContext having a virtual<br>
> forEachFile() method that takes a lambda.  The lambda is called with the<br>
> lld::File to process and it returns a bool if anything from the file was<br>
> used. The implementation of forEachFile() for each flavor knows how to walk<br>
> the input files list in the right way for its semantics.  The<br>
> ELFLinkingContext would know where the groups are and repeat the files in<br>
> the group until the lambda returns no files were used.  The<br>
> MachOLinkingContext would know to make one pass on all input files calling<br>
> the lambda on only relocatable files, then only call it on library files.<br>
><br>
> -Nick<br>
<br>
</span>The problem with this is that the linking semantics are controlled by<br>
the driver, not by the file format. GNU LD can and does link MachO and<br>
PE/COFF.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Michael Spencer<br>
</font></span></blockquote></div><br></div></div>