Simplify InputGraph and other enhancements ...

[Rui Ueyama]

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.

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/20141117/6c7e215f/attachment.html>