Simplify InputGraph and other enhancements ...

[Rui Ueyama]

Please review http://reviews.llvm.org/D6335. Unfortunately it became larger
than 100 lines but I think I managed to keep it small and incremental.

On Mon, Nov 17, 2014 at 4:32 PM, Michael Spencer <bigcheesegs at gmail.com>
wrote:

> 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
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141119/bd2683b1/attachment.html>