<div dir="ltr">Please review <a href="http://reviews.llvm.org/D6335">http://reviews.llvm.org/D6335</a>. Unfortunately it became larger than 100 lines but I think I managed to keep it small and incremental.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 17, 2014 at 4:32 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 Mon, Nov 17, 2014 at 4:30 PM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> I'm thinking to start rewriting part of InputGraph to remove excessive<br>
> abstraction, as no one seems to have opposed to the idea. This will add a<br>
> bit more code to Resolver but instead removes code and complexity from<br>
> InputGraph.<br>
><br>
> I'd like to keep the initial patch as small as possible (idetally less than<br>
> 100 lines) to demonstrate the stuff. I think rewriting code for<br>
> start-group/end-group would be a good candidate, because it made InputGraph<br>
> complicated.<br>
<br>
</span>Sounds good to me.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Michael Spencer<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> On Mon, Nov 3, 2014 at 5:10 PM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
>><br>
>> Let me do the actual rewriting stuff. I believe I have a good track on<br>
>> cleaning things up in LLD than anyone else in the project lately and I'd<br>
>> like to take this too as this is important.<br>
>><br>
>> It looks like we agreed on the idea that we should move features from<br>
>> InputGraph to the Resolver. Is this correct? It seems the reason to add the<br>
>> Tag class is to achieve that idea.<br>
>><br>
>> On Fri, Oct 31, 2014 at 4:31 PM, Michael Spencer <<a href="mailto:bigcheesegs@gmail.com">bigcheesegs@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> 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<br>
>>> > 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>
>>> They are in between FileLocators. The resolver tracks them.<br>
>>> whole-archive would also be a tag.<br>
>>><br>
>>> > Why can’t the driver pre-resolve all paths so that FileLocator just<br>
>>> > deals<br>
>>> > with full paths and not searching?<br>
>>><br>
>>> Because some paths come while reading inputs. Such as linker scripts<br>
>>> and #pragma lib.<br>
>>><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<br>
>>> > files.<br>
>>> > The remaining passes only pick out libraries and it repeats until<br>
>>> > nothing<br>
>>> > new is loaded.<br>
>>><br>
>>> The resolver will have a specific mode for Darwin linker semantics.<br>
>>><br>
>>> > When does parsing happen?  When would it not happen (as it does today)<br>
>>> > before the Resolver is even run?<br>
>>><br>
>>> 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>
>>><br>
>>> > This is where it gets interesting. The ability to have multiple “files”<br>
>>> > in<br>
>>> > one yaml disk file is great for writing one-file-test-cases.  But now<br>
>>> > 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<br>
>>> > the<br>
>>> > lld::Files, but the driver is providing the disk files.<br>
>>><br>
>>> Yes, this is an issue. It may make sense to have FileLocator also be<br>
>>> able to represent a lld::File directly.<br>
>>><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<br>
>>> > the<br>
>>> > lld::File to process and it returns a bool if anything from the file<br>
>>> > was<br>
>>> > used. The implementation of forEachFile() for each flavor knows how to<br>
>>> > 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<br>
>>> > 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<br>
>>> > calling<br>
>>> > the lambda on only relocatable files, then only call it on library<br>
>>> > files.<br>
>>> ><br>
>>> > -Nick<br>
>>><br>
>>> 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>
>>><br>
>>> - Michael Spencer<br>
>><br>
>><br>
><br>
</div></div></blockquote></div><br></div>