Simplify InputGraph and other enhancements ...

[Michael Spencer]

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