<div dir="ltr">I'm thinking to start rewriting part of InputGraph to remove excessive abstraction, as no one seems to have opposed to the idea. This will add a bit more code to Resolver but instead removes code and complexity from InputGraph.<div><br></div><div>I'd like to keep the initial patch as small as possible (idetally less than 100 lines) to demonstrate the stuff. I think rewriting code for start-group/end-group would be a good candidate, because it made InputGraph complicated.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 3, 2014 at 5:10 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><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>On Thu, Oct 30, 2014 at 10:33 PM, Nick Kledzik <<a href="mailto:kledzik@apple.com" target="_blank">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><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><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><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><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><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><font color="#888888"><br>
- Michael Spencer<br>
</font></span></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>