Simplify InputGraph and other enhancements ...

[Michael Spencer]

On Mon, Nov 17, 2014 at 4:30 PM, Rui Ueyama <ruiu at google.com> wrote:
> 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.
>
> 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.

Sounds good to me.

- Michael Spencer

>
> On Mon, Nov 3, 2014 at 5:10 PM, Rui Ueyama <ruiu at google.com> wrote:
>>
>> 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.
>>
>> 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.
>>
>> On Fri, Oct 31, 2014 at 4:31 PM, Michael Spencer <bigcheesegs at gmail.com>
>> wrote:
>>>
>>> On Thu, Oct 30, 2014 at 10:33 PM, Nick Kledzik <kledzik at apple.com> wrote:
>>> > I don’t understand these tags.  Seems like the [Start|End]Group are
>>> > *between* FileLocators (just like on the command line).  What is the
>>> > Prefer*
>>> > tag?  Does it apply just to that FileLocator, or all follow on ones?
>>> >
>>> > What about other attributes like whole-archive?
>>>
>>> They are in between FileLocators. The resolver tracks them.
>>> whole-archive would also be a tag.
>>>
>>> > Why can’t the driver pre-resolve all paths so that FileLocator just
>>> > deals
>>> > with full paths and not searching?
>>>
>>> Because some paths come while reading inputs. Such as linker scripts
>>> and #pragma lib.
>>>
>>> > I don’t see how mach-o linking will work. The driver needs to take many
>>> > passes over the whole list.  The first pass just picks out object
>>> > files.
>>> > The remaining passes only pick out libraries and it repeats until
>>> > nothing
>>> > new is loaded.
>>>
>>> The resolver will have a specific mode for Darwin linker semantics.
>>>
>>> > When does parsing happen?  When would it not happen (as it does today)
>>> > before the Resolver is even run?
>>>
>>> Parsing generally happens before the resolver is run, but sometimes
>>> the resolver will request an object from an archive that has not been
>>> parsed before. At this point it should parse it.
>>>
>>> > This is where it gets interesting. The ability to have multiple “files”
>>> > in
>>> > one yaml disk file is great for writing one-file-test-cases.  But now
>>> > every
>>> > disk file may contain multiple logical lld::Files some of which may be
>>> > relocatable or library files.  The Resolver just needs an iterator over
>>> > the
>>> > lld::Files, but the driver is providing the disk files.
>>>
>>> Yes, this is an issue. It may make sense to have FileLocator also be
>>> able to represent a lld::File directly.
>>>
>>> >
>>> >
>>> > I still kinda of like my idea of the LinkingContext having a virtual
>>> > forEachFile() method that takes a lambda.  The lambda is called with
>>> > the
>>> > lld::File to process and it returns a bool if anything from the file
>>> > was
>>> > used. The implementation of forEachFile() for each flavor knows how to
>>> > walk
>>> > the input files list in the right way for its semantics.  The
>>> > ELFLinkingContext would know where the groups are and repeat the files
>>> > in
>>> > the group until the lambda returns no files were used.  The
>>> > MachOLinkingContext would know to make one pass on all input files
>>> > calling
>>> > the lambda on only relocatable files, then only call it on library
>>> > files.
>>> >
>>> > -Nick
>>>
>>> The problem with this is that the linking semantics are controlled by
>>> the driver, not by the file format. GNU LD can and does link MachO and
>>> PE/COFF.
>>>
>>> - Michael Spencer
>>
>>
>